Keeping A Massive Site Online Using Nothing But Tiny VPS

Steve81

@yomero said: BSD sockets != UNIX sockets ???
@AsuraHosting said: Nope, I've only used UNIX Sockets. And they work absolutely amazing.

Sorry, with bsd sockets I mean unix sockets (afaik unix sockets descends from bsd sockets).

I finally found some references. The nginx behaviour is to throw 502 if cannot connect to the socket (normally during an high load):

http://goo.gl/KyINm

http://goo.gl/3nRh1

http://goo.gl/J6chJ

http://goo.gl/iH2DY

http://goo.gl/qmoly

Tuning some system settings helps (but at least in my experience didn't resolve the problem).
On a low end box I don't think that is a good solution to use nginx with php + unix sockets, expecially when others webservers doesn't suffer from this problem (that's mean that they can handle a small spike of traffic without starting to throw out errors).

AsuraHosting

@Steve81 said: I finally found some references. The nginx behaviour is to throw 502 if cannot connect to the socket (normally during an high load):

That's probably because you chose to use FPM... why not use FastCGI?

http://wiki.nginx.org/PHPFcgiExample#Connecting_Nginx_to_the_running_FastCGI_Process

I even stated in my 1st post... use FastCGI.

@AsuraHosting said: nGinx + PHP FastCGI, configure to use sockets instead of :9000. It would be able to handle a lot of traffic/requests, and keep resource usage minimal.

Steve81

@AsuraHosting said: That's probably because you chose to use FPM... why not use FastCGI?

Well, first of all I chose FPM because IS a FastCGI implementation. So yes, I use fastcgi directives in nginx configuration.

php5-cgi have, afaik, worst performance.

Doesn't seems to me very clever to use an implementation that have worst performance just to avoid to use a webserver that doesn't show the problem.

If you read the first two/three links that I put in my post, you can read that is a nginx implementation problem (how nginx manage unix sockets), rather than a FPM problem.

As I previously assert, there are other webservers that doesn't show this problem and works nicely in low end boxes.

edit: A small edit, because I like the way of saying: "better safe than sorry".

I did a test with php5-cgi & spawn-fcgi and with php5-cgi and the script from the nginx page, just to discover (surprise surprise) that bring the same problem (with around 250 concurrent connection, but the machine is quite loaded; I suppose that on a more light machine i'll see the problem on 300).

2012/02/06 03:50:27 [error] 6014#0: *1898 connect() to unix:/tmp/php.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/tmp/php.sock:", host: "127.0.0.1:8080"

Ofc, no problem with another webserver and php-fpm.

AsuraHosting

@Steve81 said: Well, first of all I chose FPM because IS a FastCGI implementation.

Did I say it wasn't? No.

@Steve81 said: php5-cgi have, afaik, worst performance.

It really isn't that bad; Sure, FastCGI < Spawn < FPM.

@Steve81 said: If you read the first two/three links that I put in my post, you can read that is a nginx implementation problem (how nginx manage unix sockets), rather than a FPM problem.

And the information you've posted is almost 2 years old. Nginx isn't at 0.7 anymore... so I just considered it irrelevant information.

I'll get PHP-FPM w/ UNIX Sockets on Nginx for you; I seriously doubt it has those problems. It runs absolutely fine for me on FastCGI w/ UNIX Sockets.

Edit; Just like to add... you shouldn't be so stubborn about this. Plus there's no need to make someone else look like they're wrong. I'm pretty accurate about my information and I've had experience in using what I've advised. You better put yourself in check and watch how you say things towards other people; when you show disrespect to others, then you'll only be disrespected right back.

AsuraHosting

@Steve81 said: 2012/02/06 03:50:27 [error] 6014#0: *1898 connect() to unix:/tmp/php.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/tmp/php.sock:", host: "127.0.0.1:8080"

Hey Steve, nice job trying to fake an error; hahahahahahaha, hilarious!

http://forum.nginx.org/read.php?11,184952,191486

Steve81

@AsuraHosting said: Did I say it wasn't? No.

You said that I should use FastCGI, that's imply that I wasn't using FastCGI.

@AsuraHosting said: And the information you've posted is almost 2 years old. Nginx isn't at 0.7 anymore... so I just considered it irrelevant information.

Fine. You didn't read all the thread where the nginx creator said that there isn't a solution, did you?
Also, I suppose, you didn't read the nginx changelog to check if something was changed, did you?
I did that.
I made my first test with nginx 1.0.x, last year. I got the same results on different machines.
Also the 4th links that I put in my post is from sept 2011, nginx 1.0.2. Not a geological eras ago, seems to me.

@AsuraHosting said: I'll get PHP-FPM w/ UNIX Sockets on Nginx for you; I seriously doubt it has those problems. It runs absolutely fine for me on FastCGI.

Test it on a low end vps, not on a big server.

@AsuraHosting said: It runs absolutely fine for me on FastCGI.

How many concurrent connection? How many childs? Machine specs?
As I said, try to siege it with a good number of concurrent connections.

Steve81

@AsuraHosting said: Hey Steve, nice job trying to fake an error; hahahahahahaha, hilarious!

Do you want the errors.log?

edit:

I'm happy that an error line, that report the same error, make you laught.
You didn't think that hardly a developer change the structure of an error line, did you?

I've updated my nginx to 1.0.11, debian package from nginx.org.

Here the logs.

Siege log (notice the 200 ok, sometimes)
http://pastebin.com/7a2vww5y

Nginx error.log
http://pastebin.com/kQxpvrJb

However, now I don't like your behaviour. I'll avoid to reply to you anymore.

Have fun.

cleonard

I guess I have a different idea of "massive." A site that runs on two boxes is not massive as far as I'm concerned.

There is a lot of likely valid suggestions, but unless you know the details on the processing usage, it's pretty much impossible to give any kind of optimum solution.

100% reliability is not possible, but you can get close.

AsuraHosting

@Steve81 said: However, now I don't like your behaviour. I'll avoid to reply to you anymore.

It's funny when the tables turn; when I show you the same amount of respect you've shown me... you decide to run away.

Anyways, I replied with the thread stating the same exact error; you, as a "developer" have improperly set it up right. Maybe you should actually set it up properly before running tests...? Just my 2 cents.