Erik Onnen (rightly) calls BS on the Apache vs. Yaws comparison. maybe his call out will dig up more details or lead to better comparisons.
/But likening the Erlang community to Microsoft is going too far. :-/
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
Erik Onnen (rightly) calls BS on the Apache vs. Yaws comparison. maybe his call out will dig up more details or lead to better comparisons.
/But likening the Erlang community to Microsoft is going too far. :-/
3 comments:
Sure, the delays between characters are unrealistic, but they are designed to show what happens when lots of TCP connections are coming in to your apache box.
The results simply show Apache's weak concurrency model. POLL a few thousand connections and Apache will start dying-- regardless of OS or kernel version.
That's why event-driven servers like Zeus or Lighttpd are preferable in high concurrent load situations. FWIW, the Juniper DX load balancer itself is an event-driven web server that can scale to 500,000 + concurrent connections.
Scaling to lots of simultaneous users is all about how you handle concurrency. And Apache doesn't do a good job.
See http://www.kegel.com/c10k.html for other points.
Speaking of comparisons involving Microsoft, have you looked at the waves Mozilla's Prism is making in the RIA space?
israel, that's unfortunately a bit of a dated analysis of Apache, roughly about three years out of date. Apache HTTPD is built on apr which uses the most suitable kernel polling implementation available, much like libevent. On Linux for example, that translates into epoll calls rather than polls, the difference in which is substantial.
I'd encourage you to test Apache mpm-worker against lightttpd on a platform that supports modern async I/O - every time I've done it Apache has slightly won out and is always on par with lightty. This includes Linux with epoll and kqueue on BSD.
Post a Comment