Nginx vs Apache - Are there any actual usage comparisons and statistcs out there? I have a new server to play with, and I am staring at a blank canvas. I can put anything I want on it. While I am comfortable with Apache, I keep hearing how nginx can handle so much more traffic than Apache, by factors of 10, 100, even more. Not only that it's "much much faster."

When I search for articles I can find lots of stuff unrelated to Drupal. Or, when I do come across a Drupal related article it's either 1) someone's configuration file with a quick attempt at explaining how to set it up, or 2) it's someone saying "no, don't use nginx, go with Apache with PHP fcgid" but there is never explanation as of why.

So, when it comes to Drupal, what is the reality here?

As an example, I am looking for something along the lines this 2bits.com article.  Here the author has taken a pretty extensive look at Apache mod_php vs Apache with fcgid, weighing the pros and cons of each, and provided a case study to illustrate the impact in the real world. There is enough information in this article for me to make an educated decision as to which approach would be best for my situation.

While that author compares mod_php to fcgid, I am looking for the same type of comprehensive, real world look at Apache vs Nginx.

Anyone switched to Nginx and been "blown away" by the difference it made compared to Apache? Even for highly optimized environments that are already using APC, Memcache, and aggressive caching like Varnish, when the only variable that changes is replacing Apache with Nginx, does make enough of a difference in and of itself to merit investing in this newer, alternative technology?

The site that will go on this server gets an avg of 2 million PV a month. LAMP stack running Cent OS 6. 4 core CPU with 8 GIGS of ram. Memcached and APC will be part of the mix. Nothing special about the Drupal install - basically vanilla 7 with about 50 modules.
Strictly speaking, this doesn't answer the question you are asking. I'm hoping it's helpful anyway.

Apache/Nginx/Lighttpd/other web server. Does it matter which one I choose? In short, No.

The much much longer answer:

If, and only if, you have a very large percentage of your users being logged in, should you care at all about the performance of your web server. If your users are anonymous, any difference that you can theoretically derive from optimizing at that layers absolute pales compared to making your resources better cacheable. If your css files have proper cache headers on them, the UA won't even ask for them the second time. That matters. If you can cache your pages in Varnish or a similar software solution, then serving that page is a matter of making a hash-lookup, and then returning a large chunk of data directly from RAM. That matters. In both of these scenarios, the HTTP daemon is never even involved, PHP does not get invoked. Drupal does not bootstrap. No large set of modules must be loaded into RAM, no time consuming database queries are executed.

When you perform a full page load, from a cold cache, for a logged in user, on a complex page; a lot of things are going on. Yes, the web server is involved in dealing with the incoming request, setting some headers and passing the response back. But the time that takes, is not even relevant in the context of Drupal running a full bootstrap and outputting its response. There could be hundreds of database queries being executed. Highly complex logic in PHP is evaluated by the parser. Lots of modules are being loaded into RAM. Improving the performance of any of those things, are much more likely to make a serious contribution to performance.

For the sake of argument: Let's say you have spent a lot of time performance optimizing everything else.


You run APC (Or Optimizer+) and the latest and fastest version of PHP.
DB-queries are few.
PHP logic has been reduced.
You cache what you can in Varnish.
You have re-structured your entire site so that you can cache a lot client side, and do lots of heavy lifting in ECMAScript.


If you have a lot of logged in users, and you've dealt with all of the above, then you can probably make a difference but performance tuning, or replacing your web server. However, guess what. Your site is so complex, and the usage patterns of your particular users, is unique. There is no generic answer. You will need to setup all different web servers behind a load balancer, and see how they behave, under your scenario.

The above was an attempt at logically reaching the conclusion that spending time performance optimizing the web server is likely a bad use of time. I would love to have someone pick holes in the above though, I would probably learn something new from it. :)

Some other notes:


During the DrupalCon Copenhagen keynote, PHP creator Rasmus Lerdorf, using Nginx himself, speaking on the topic of Drupal performance, said "People always ask me about web servers ... it really doesn't matter, the web server is pretty much irrelevant". (Roughly at 26:30 in the video)
Facebook has spent countless hours on writing Hiphop, a code base significantly larger than Drupal itself, for accelerating PHP-code by a "measly" 100%. I examined Hiphop with $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1 and found it to consist of 1.512.481 lines of code. That's an absolutely insane amount of work put in to improving the speed of PHP. I'm guessing that's because the speed of PHP matters greatly to them.
Did I mention that good caching is going to have a much greater effect that tuning the web server?
With the release of Apache 2.4, Jim Jagielski basically claims that Apache 2.4 is faster than event based servers.
I attented Drupal Performance and Scalability with The Dream Team, where just this question came up. All the answers about which to choose, was unrelated to performance. Things like "Which one do you already know how to configure", and "Which one will allow you to build the simplest technology stack", were among the reasons mentioned to pick on over the other. Performance did not enter the picture.