How to handle 1000s of concurrent users on a 360MB VPS

Why use nginx instead of Varnish as the frontend proxy? If you are using nginx as your http &#60;-&#62; fastcgi gateway, that's one thing, but if you're just using it as a reverse proxy, it seems like a lot of extra stuff to maintain.<p>I like living on the bleeding edge, so I do varnish -&#62; mongrel2 &#60;-&#62; apps instead... but varnish -&#62; nginx &#60;-&#62; apps or varnish -&#62; apache &#60;-&#62; apps seem equally reasonable. The key is caching and being able to handle slow users without tying up your app. All three of these setups do that. nginx to apache only saves your app server; it doesn't do much caching.

This is surreal. I just wrote a draft blog entry about the changes in startup economics due to event-servers like node and nginx (publishing tomorrow), and I hit HN just before heading to bed and this blog entry is #1.<p>Thanks for all the love today guys. Have an awesome memorial day weekend if you're in the States.

I use nginx exclusively as my server and I run node instances and wordpress behind it. Why even use apache?

At the end of the article, why is apache even being used anymore?<p>Just use nginx and php-fpm (or php-cgi/fcgi).

Missing: caching. Caching. Caching. And more caching.<p>I speak of Wordpress and database-backed PHP applications of its ilk. Wordpress loves to spray MySQL in a thick stew of queries for every single page load.<p>Without sensible -- preferably aggressive -- caching, your Wordpress site will die in the arse.<p>My setup generates cached .gz files, which nginx can serve directly. It <i>flies</i>. It didn't used to.

This technique naïvely assumes the only thing that is slow is the client. If a backend data provider that the web server communicates with (e.g., database) is also slow, this arrangement merely adds complexity without much corresponding benefit. The origin server will still block waiting on the data provider, which can cause process starvation in the pathological case.<p>Moreover, issues with slow clients often can be solved by raising the TCP send buffer size. As long as the response size is less than the send buffer size, it really doesn't matter how slow the client is: write() will return immediately, leaving the webserver free to serve the next request. Getting the data to the client then becomes the kernel's responsibility.

Worth noting the the story is from Dec '09.

As a good number of folks have pointed out, this article (helpful for sure) is <i>basically</i> nginx + PHP-FPM.<p>nginx servers up static content (e.g. if you are using WP-SuperCache and it's generating those static cache files for you, JS, CSS, images, etc.) then you configure a pool of warmed up PHP VM instances via PHP-FPM (Check /etc/php5/php-fpm or some equiv dir on your server).<p>Then you setup a rule that directed PHP requests to the FPM service, that would probably look something like this in nginx:<p><pre><code> location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/mysite.com/$fastcgi_script_name; include fastcgi_params;</code></pre> }<p>and instead of adding the layer of Apache servicing the PHP requests, you are having nginx pass through the PHP requests <i>directly</i> to PHP processes to run.<p>Going from an Apache2 + FCGID configuration (somewhat similar to this, but with Apache) to nginx, I saw a 75% drop in server load.<p>I'm almost certain <i>this</i> still isn't a totally tweaked out setup that someone more familiar with this process could do better, but for my needs it took my server crashing under load no matter what I did, to typically being idle most of its life (~900k/month pageviews)<p>So I'm a big fan of nginx. I'm not saying you couldn't configure Apache to do the same... just 5 years of attempts to do so never got me anywhere with it.

Repost: <a href="http://news.ycombinator.com/item?id=970682" rel="nofollow">http://news.ycombinator.com/item?id=970682</a><p>Interesting comments on the original thread.

I just find it odd that Apache hadn't employed the likes of epoll already. IRC servers have been using async sockets like this for yeeeears.

Are the loopback requests limited by the TCP stack?<p>Is it possible to set this up where nginx and apache communicate via a socket?

You can do the same on a really high traffic Drupal site using the boost module. It's basically a module that will, for non-logged in users, generate a static html page and serve that instead. PHP isn't even called, the .htaccess just serves up the cached content.<p>And that's using Apache!

Dropping keepalives actually slightly hurts your best-case performance. As a config change, if you are using the prefork mpm (I wouldn't if scalability is your goal) it will generally help you though. With prefork the scaling math on worker memory * connections vs your box's memory is often the first place things will fall apart if you have keepalives on and real traffic.<p>I suggest the worker mpm if you don't want to switch to nginx.

Hint: you can just run Apache twice; once with a mpm_prefork config for your apps, once with a mpm_event config to handle client connections.

I've been on Apache servers for years, so I come from that frame of mind. My managed VPSs are running Apache, and one of them is running nginx for static resources. I think my managing host (Servint) doesn't even support nginx. How, for argument's sake, would I move my PHP/MySQL sites to run on a managed nginx server?

I use straight nginx on Fanboy Adblock (which gets hundreds of SSL connections per minute), no need for Apache.

This approach really works well... I would add that off-loading MySQL to a different VPS within the same network works well too; latency within the same network is very negligible. Doing simple optimization such as moving/disabling mail and stuff you probably dont need works too.

nginx is actually pretty bad at all benchmarks I've thrown at it, you can see some here: <a href="http://www.webhostingtalk.com/showthread.php?t=918355" rel="nofollow">http://www.webhostingtalk.com/showthread.php?t=918355</a> this was on an 8 core intel Xeon 5520 server system it maxed 8 cores (18ghz) @ 7500 requests per second for static content.