Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wow, I haven't run my own webserver in a while, but if what you say is true it's remarkable that Apache can be so bad.

If Apache really uses 7-9x more resources than nginx, that speaks more to Apache's awfulness than nginx's awesomeness. You can beat a worthy competitor by 50%, maybe even 100%, but if you're winning by 700% then your competitor is just bad.

I wonder what it does that is so inefficient.



Given the choice, I'll pick Nginx over Apache any day, however saying that Apache in this case was the problem is just plain FUD.

The OP just had no idea how to set it up properly or made a serious mistake somewhere.


I'm curious. Do you have any thoughts on what he might have setup in the wrong way?


> I would point out that the server load with nginx running with NO CACHING (WP-SuperCache disabled, all queries execute PHP and perform a MySQL query) was something like 1/4 what my Apache/MPM/FastCGI/PHP/WP-SuperCache-enabled setup was using.

This does not compute - no caching (the use of nginx is irrelevant) will always be slower than caching, especially supercache which creates static files for the server to serve directly - even apache can serve those faster than nginx+memcached of the article.

So I would have to say that his caching system under Apache wasn't working.

That would fit the numbers better.

It is true that nginx will perform better than a badly tuned Apache system in the event of a slashdotting but only because it alleviates the slow client problem ie.:

You have 400 concurrent visitors, each one takes up a thread on Apache causing it to saturate, whereas nginx will buffer the request from the client, send it all in one go to the backend, buffer up the response, freeing the backend for another request - an Apache thread would be unavailable for the entire time of that request.

However you can get the same behaviour just reverse proxying from nginx to Apache.

This is all moot though, you can handle even a slashdotting on a 5$/year vps - just make a static version of the page being hit, and serve it directly until the load dies down. 99.9% of requests will be for that page only.


He might have had keep-alives enabled. Apache + keep-alives + slow clients is a recipe for disaster. Seems everyone learns this the hard way. I learned it the hard way in 1998 when the Starr Report was released and my web farm was running Apache on Ultra 2's.

patio11 learned it the hard way recently too http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memo...

Amusingly, patio11's "Memory-Constrained VPS" have the same amount of memory (512 MBs) as those Ultra 2's I mentioned (I think, they may have actually only has 256 MB at the time).


The answer is to put something like Nginx in front of Apache. Let Nginx serve the static resources. Turn keep-alives off and let Apache serve the dynamic stuff. Also disable every module in a Apache that you don't know what it is doing and re-enable them as you understand them to make your site work.


Apache isn't that bad. I haven't used nginx, so I can't speak to it, but the reason I haven't is that I can push 500+ Mbps out of a single box running Apache with just some basic configs. mod_php may be slow, but Apache itself is plenty fast.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: