4 ms·
You may want to take a look at http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-faster-than-apache-w-mod_php/ http://www.eschrade.com/page/why-is-fas
by FooBarWidget 14y ago
You may want to take a look at http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-faster-than-apache-w-mod_php/ 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... :(
- apinstein 14y agoThat 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 :)