2 ms·

Apache traditionally used a pre-fork model. Later work has been expended on moving away from this model: http://httpd.apache.org/docs/2.2/mpm.html http://httpd.

Apache traditionally used a pre-fork model. Later work has been expended on moving away from this model: http://httpd.apache.org/docs/2.2/mpm.html http://httpd.apache.org/docs/2.2/mpm.html I attempted to address both pre-fork and fork-per-request above -- both involve mapping one connection to one process -- this is resource intensive, and should be replaced with more modern event-based multiple-connections-per-process (select, poll, kqueue, etc.) approaches.

davidw 17y ago
Ok, just so it's clear that Apache's prefork mpm forks to handle concurrent connections, but does not simply fork() each and every time a new connection comes in, which some people naively believe. It does use select to handle requests that are arriving, and then farm them out. This model does scale pretty well though - you can saturate a T1 with Apache just fine. Also, it's a pretty decent model for when your connections are causing something to do work (like running a script which hits a database). If you have everything in one big poll()-happy process, you still have to farm things out to separate processes if they risk blocking. Well, unless you're using Erlang, which has a scheduler of its own so that its processing doesn't block. Moral of the story: event based servers are faster/smaller/more efficient when it comes to serving static content. When you start doing more than that, things get more complicated and you generally need to offload work to processes/threads/something in any case. Which is one reason why Apache has always been quite popular, despite the presence of whichever select/poll based server du jour.