e.g. modmemcachecache
Nginx vs Apache performance
11–20 of 49 posts
Re: Nginx vs Apache performance
#12My understanding is that Nginx is the server of choice for static content and Lighttpd for dynamic content (particularly FastCGI). Is that still the latest and greatest advice? 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.
There's no need for Lighttpd when you use Nginx. It can do everything that Lighttpd can do and more (and has no memory leaks).
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.
Re: Nginx vs Apache performance
#13How does Nginx compare to lighttpd?
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
Re: Nginx vs Apache performance
#14Earlier quoted context omitted.
Depends on the app platform. In the rails world Phusion Passenger (aka mod_rails or mod_rack) in combination with Apache is making inroads for serving up dynamic content. Despite the bigger footprint and other downsides of Apache, I'm hearing more and more that stability and ease of configuration of Passenger are a win. I'm only running it on a low usage backend app for the moment, but it was definitely easy to set u…
Am I misunderstanding something, or is Phusion essentially just a slightly better FastCGI? 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.
Re: Nginx vs Apache performance
#15Earlier quoted context omitted.
There's no need for Lighttpd when you use Nginx. It can do everything that Lighttpd can do and more (and has no memory leaks).
Interesting... 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.
Re: Nginx vs Apache performance
#16How does Nginx compare to lighttpd?
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.
Re: Nginx vs Apache performance
#171. 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.
Re: Nginx vs Apache performance
#18Does anyone(anything) package php-fpm (or whatever you are supposed to use) together with nginx?
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.
Re: Nginx vs Apache performance
#19How does Nginx compare to lighttpd?
Re: Nginx vs Apache performance
#20My understanding is that Nginx is the server of choice for static content and Lighttpd for dynamic content (particularly FastCGI). Is that still the latest and greatest advice? 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.