Hacker News new | past | comments | ask | show | jobs | submit login

I think ngninx is likely faster and more stable than apache, but I have yet to see anything close to a trustworthy benchmark.

I come from the php world, and people always say how much lower-memory nginx+php-fpm is than apache+mod_php. Well no doubt! If you understand how the architecture actually works, it's clear this isn't a fair comparison. mod_php means php is fully-loaded for serving statics, not to mention having a smaller pool of php-fpm processes will take less memory and also be faster (due to less context-switching) than the larger number of mod_php processes.

However the real comparison should be between nginx+php-fpm and apache+mpm_event+php-fpm. Nginx is an evented server, so at least try to compare apples-to-apples. I've seen very few comparisons of nginx with mpm_event.

Also, apache's default tunings are much more geared towards modest server usage whereas nginx's seem more geared towards high scalability. An argument could be made that apache should have "better" defaults, but since at scale you need to start tweaking your OS/rlimit/etc to prevent bad things from happening you can see why apache might stick with more modest tunings ootb.

Our app has a lot of apache custom config and so I was a hesitant to try to switch to nginx due to the risk of getting things wrong porting the configs. We did move from apache/mod_php to apache+mpm_worker and php-fpm and we've been able to improve throughput (especially on statics) at a far lower memory footprint. Key to success in lowering the memory footprint was dropping ThreadStackSize (from 8M default to 1M). What a difference!

Other than that, the competition is good for everyone. I am sure nginx pushed apache to work on mpm_event much harder.




You may want to take a look at http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-.... The answer might surprise you.

As for ThreadStackSize: it impacts virtual memory but not actual memory usage. Actual memory usage stays the same. You should never use the 'vm size' as a good measurement of memory usage. Unfortunately memory management on modern OSes is complicated and people don't understand the numbers, so they arbitrarily pick a column in 'ps' and conclude that X is bloating memory... :(


That link about AllowOverride is true. The reason I didn't mention it is that one of the benchmarks I saw did turn off AllowOverride so I figured at least that part was fair :) But it is a very good point. I think I'll do a talk soon about tuning apache and make sure that's in there. Optimizing with strace is always really fun. I used it pretty heavily when I was researching php/apc and require/require_once. It's amazing how much faster you can get if you implement things to not talk to the disk 20x on every request :)

I definitely know VIRT is complicated. I couldn't find any kind of clarity on it. If you know of a good guide I'd love to see it.

That said, virtual memory still likely affects some kernel decision-making. For instance the oom-killer was kicking in on a daily basis until I made these changes. With mpm_worker using 250+ threads, I was able to reduce the "committed" by several gigs. The system overall seems more stable and the oom-killer hasn't reared its head in days.

I can imagine that the stack is treated differently since it'd be a terrible idea to page out stack. I couldn't find proof, but if I were a kernel I wouldn't page out stack :)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: