Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For years I have been using the mpm-prefork module as it was my understanding that this was the preferred worker for Apache 2 and 1.3.

Now I will be installing some fresh Apache servers and will be using the newer 2.4 version, with which the event based mpm which uses epoll/kqueue.

I know in the last few years event based systems have become all the rage (e.g. nginx, lighttpd, node.js), so since mpm-event is now stable in Apache, is this the preferred multi-processing module to use?

I also took note of the comment from the mpm-event documentation page:

The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection.

Our main site forces an SSL connection, so it is clear that we will not benefit from the improved connection handling related to keep-alive, but is my understanding correct that there will still be some performance improvement since there will be less threading taking place?

share|improve this question
up vote 6 down vote accepted

The prefork MPM has not been the "preferred" MPM for many years.

The reason it is still the default for many distros is that some third-party libraries have trouble with the threading in the worker MPM (which has been the preferred MPM since version 2.2).

Not modules like mod_php, which is quite thread-safe, but libraries used by modules like mod_php, such as mysqli etc.

In 2.4, we have now switched to the STABLE event MPM.

The release is still very new and the documentation has not been completely updated to reflect this.

As has been the case for years, if the prefork MPM is causing you grief, switch to threaded serving and run your dynamic content via fastCGI.

share|improve this answer
Thanks for the good info. We don't have any problems with prefork but if some performance can be gained with no side effects to the application, I'll try it. – drew010 Mar 14 '12 at 3:04
"Some"? Seriously ? If you're running prefork on a 4GB machine with 200 concurrent connections (and you're running out of memory), you can replace that with worker and fastCGI and serve over 2000... – adaptr Mar 14 '12 at 8:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.