Apache vs nginx vs lighttpd (And Cherokee!)

[Jesse]

Awesome thread

 

[jpavsex]

Great Detail

Thank You

 

[Hecker]

How do you call it "en jinx"?
It's kind of obvious, knowing what nginx is, to assume it is pronounced n-gin-x.

 

[Lifetalk]

Lol, does pronunciation really matter? I thought we were more of discussing how it's performance is superior over others, and such.

 

[onel0ve]

great post thanks :x

 

[XSLTel]

I would say and from my experience you can get great performance from Apache if you know how to tune it and understand the work of every directive .

most people set AllowOverrid directive to All in <Directory /> and that unfortunately decrease Apache webserver performance and increase Apache overhead searching for .htaccess files in every directory per request. (per request means its not cached imagine 1000 request per minute that will make Apache to look for .htaccess 1000 times in 1 minute).

the above is just 1 example of bad Directives using. it would give you a small idea of how big Apache is.

Apache is best web server in the world.
Nginx is great for reverse proxy and flv streaming solutions . (I use it personally)

Highest Regards
Mohammed H

 

[Lifetalk]

At the end of the day, Apache still is inferior in terms of performance under a high load situation. Primarily because of the fact that it forks a new process to handle a new request that is not already handled by an otherwise child that's free. Compare that to the multi-threaded processes on nginx/lighty/cherokee.

I've, myself, had an exponential performance gain using Cherokee instead of Apache. Where Apache would stall for me after I had like 100,000 images hosted (and about a few thousand requests per minute), Cherokee's still going strong at over 600,000 images and there's still room for more.

 

[XSLTel]

Lifetalk have you ever used Apache MPM Worker, Event.

just to let you know Apache already have multithreaded MPM but none benchmark that I don't know why?? (I guess it's human nature though), I personally have used it, it will fork only 1 processor and that processor will handle all requests through threads.

Highest Regards
Mohammed H

 

[bhanuprasad1981]

I would say and from my experience you can get great performance from Apache if you know how to tune it and understand the work of every directive .

most people set AllowOverrid directive to All in <Directory /> and that unfortunately decrease Apache webserver performance and increase Apache overhead searching for .htaccess files in every directory per request. (per request means its not cached imagine 1000 request per minute that will make Apache to look for .htaccess 1000 times in 1 minute).

the above is just 1 example of bad Directives using. it would give you a small idea of how big Apache is.

Apache is best web server in the world.
Nginx is great for reverse proxy and flv streaming solutions . (I use it personally)

Highest Regards
Mohammed H

Bro Mohammed H, can you please create a thread with helpful tips to tweak apache , it will help lot of guys like me

 

[okone]

My view with apache...there is no use flogging a dead horse.

I recently moved another one of my sites to the 'ol nginx and fpm combination and it runs far better than before. Plus now that php-fpm allows dynamic process spawning, its as good, if not better than apache.

At this point some of you are probably going to flame me about the difficulty of using nginx rewrite rules. Well, I have one answer for you: try_files. Problem solved.

Nginx ftw, apache for the bin!

 

[Perl]

Very helpful

 

[MyBB Hoster]

What are they saying about these now? At this point in life whats better?

 

[GeekHosting]

cool....
Thanks for sharing with us!

 

[vbnet]

+1 for nginx.

For lighttpd, I'd stay away from it. Lighttpd doesn't flush the cache, no matter how, all files will be kept in memory.

 

[Nsane]

Hands down to nginx. I always try to use this on my servers when I can as I know for a fact it makes a big difference in the end.

 

[perfectRDP]

Apache2 worker mpm method also good for advanced performance.