Nginx vs Apache performance
blog.webfaction.com
blog.webfaction.com
1. Don't run the client on the same server. If you do, you have no business trying to test for high concurrency. Isolate the variables.
2. Size of file you are serving. Are you close to saturating your connection between the client and server? Most of the time this is the case.
3. Concurrency is hard to test because most of the time the client is the problem in the test. Don't use apache bench for anything like this as it's high concurrency is much to be desired.
4. A lot of other details need to be compared to make a benchmark useful. Are you using keepalives on both/or not. Nginx workers/processes vs apache threads/clients. Are you comparing apples to apples? How's your TCPIP backlog in a case like this? What kind of IO model are you running on each? Are you using sendfile on both or only one?
Nginx is a great server, and probably a better choice for static files, but data like this is like saying, "the other day I saw a some kind of Honda pass some kind of Nissan". No useful information to infer about either.
At its heart nginx is a fork of apache 1.3 with the multi-processing ripped out in favor of an event loop (and all the copyright statements removed from headers, but hey, it's cool). The event loop, time and again, has been shown to truly shine for a high number of low activity connections. In comparison, a blocking IO model with threads or processes has been shown, time and again, to cut down latency on a per-request basis compared to an event loop. On a lightly loaded system the difference is indistinguishable. Under load, most event loops choose to slow down, most blocking models choose to shed load.
A few short years ago the benefits from using an event loop instead of blocking io were much more dramatic -- the level of parallelism achievable in hardware has gone way up (hey, look, erlang!) and is accelerating. Paul Tyma did some great experimentation with this a while back, http://is.gd/nJ6Z .
It comes down to the original issue of Linus Torvalds, Ingo Molnar and Con Kolivar: do you have a clear roadmap of where the architecture is going, vs a very cool technology that had a lot of support and was no doubt popular.
I am in no way commenting on the technology behind nginx, but as an architect, making a deployment decision that is going to take hell to change later, I would be very concerned.
I've found Lighttpd way easier to configure than Apache and am having it serve my static content simply because we don't need to worry about every little bit of performance just yet.
Our app is Python 2.5 and Django (well, kinda Django). I haven't gotten to deep into the Lighttpd thing yet, but it looked promising. Maybe I should take another look at Nginx?
Also, do you recommend FastCGI or WSGI? I've had a hard time figuring out precisely what the differences in implications are.
I also use nginx as proxy in front of apache and dev instances of django manage.py runserver (nginx serves up static, passes dynamic on to back ends)
Nginx is so powerful, flexible, and has never given me a single problem. I loves it.
It does some magic sharing of read-only segments of memory by taking advantage of copy-on-write and a special version of Ruby, but other than that it seems like it does the exact same thing as FastCGI.
Well, it depends on whether you're looking at it from an academic or practical standpoint. AFAIK the technologies are not entirely dissimilar, as you suggest, but there are notable differences once you actually put them into use. I've used both for running rails apps, and a few things stand out for me:
1. Passenger is much easier to set up: it took me about 5 minutes to get my first Passenger based rails app up and running. The last time I set up a rails app w/FastCGI (admittedly a few years ago now) it took me much longer. This comes down to simpler configuration combined with better documentation. Subsequent application deployment is also easier (no manual server restarts required). This is worth a lot in practical terms, even if not flashy.
2. Passenger seems more stable. I never had quite the problems with FastCGI that others appear to have had, and I've only been using Passenger for a few weeks now, but there's a reason people used FastCGI less often once Mongrel became available.
3. Oh, and there's some neat stuff too: automatic spawning and pruning of application instances in response to demand, etc.
With Passenger, I set it and forget it. Time is money.
I've been using NGinx/Mongrel for most of my large deployed apps, but am working to get things moved to Passenger (and Apache, natch), simply for the ability to do a graceful restart on most code changes. For large apps, the ever expanding mongrel footprint and slow restarts is becoming too much to bear.
So for me, Nginx has a lot to offer over Apache, but with the rails deployments I've been working on mostly, it's no longer enough.
Many internet years latter I believe the momentum has shifted to nginx (http://news.netcraft.com/archives/2009/01/16/january_2009_we...) and it has so much going for it, check out the modules and add ons http://wiki.nginx.org/NginxModules
But if you really care http://www.google.com/search?q=lighttpd vs nginx
http://news.ycombinator.com/item?id=319301
In brief, nginx is a glorious piece of software. Despite a strong early showing in 2006-2007, lighttpd isn't.
Lighttpd has a bug in mod_proxy that makes it unusable under load.
A thousand times no. Nginx+php-fastcgi is screamingly fast by comparison, while allowing me to free up about 70% of the memory previously in use, and get huge gains from loading the PHP code into RAM with APC.
I look after one managed server which chucks out tens of millions of requests per day despite only having half a gig of RAM in it. Before, running apache2, it had a load average of about 6.0. Now? 0.2.
e.g. modmemcachecache
nginx or varnish reverse proxy front end. (depending on your load you can turn keepalives on here) This front end isolates your www/php/db from slow clients making sure that your request gets processed fast, resources are released, and then a light process of your proxy handles the delivery of the data. On the back end use apache/mod_php with a limit of only 50-100 clients.
note that by not using apache you give up a lot of security hardening, add-on-modules, and mindshare that nginx does not have.
For example I tried running a server with apache + passenger on an ec2 node, bumped up the MaxClients to 1024. I evened out at around 400 simulaneous connections. Maybe it was due to some mysql limit or limits from the placed I sent the load from, but I was consuming around 50% cpu, so there seemed to be some other thing.