56

Based on the descriptions for both the Prefork and Worker MPM, it seems the prefork type is somewhat outdated, but I can't really find a proper comparison of the two types.

What i'd like to know:

  • What are the differences between the two versions?
  • What are the (dis-)advantages of each server type?
  • Are there any basic guidelines on which type to choose based on the conditions?
  • Are there any big performance differences between the two?
1

5 Answers 5

40

As the docs say, you should use the prefork MPM if you need to avoid threading for compatibility with non-thread-safe libraries. Typically, any non-trivial Apache module (mod_php -- or, more precisely, the myriad of extensions and libraries that it links to -- being the canonical example) has some sort of non-thread-safe library (or has non-thread-safe code in it), so unless you're using a pretty stock Apache install, I'd go for the prefork MPM.

5
  • 3
    I would have recommended the worker MPM, unless you're running PHP. Worker is the recommended MPM from apache, and gives better performance and lower overhead. It's only that PHP developer have never heard of thread-safety that you need to use prefork. Jul 24, 2009 at 13:05
  • 16
    PHP has been thread safe for a very long time. They only suggest the use of pre-forkers as they cannot control what other libraries do. Quit blaming PHP for others developers inactions. Jul 24, 2009 at 13:59
  • 3
    PHP may be thread safe (although I doubt it) but all the libraries that it links to are definitely not. Here we run a few fairly large PHP applications and every couple of months we try to switch from prefork to worker, but we get corrupted data straight away. Jul 24, 2009 at 14:04
  • 5
    At least function changing ENV variable will not be thread safe, setlocal php.net/manual/en/function.setlocale.php is a common exemple of that.
    – radius
    Jul 24, 2009 at 17:27
  • 5
    One note: These problems do not apply if PHP is attached e.g. with php-fpm via FastCGI. Then the worker MPM is just fine -- then the fpm will run every PHP request in an own process while the Apache can run threaded. The PHP-Thread-safety problem only prevents you from using mod_php, which runs PHP inside the Apache process.
    – mschuett
    Oct 21, 2012 at 18:57
14

The classic solution to running unsafe extensions while serving large numbers (>100) of concurrent connections is to run PHP on fastCGI (mod_fcgid, a native apache module) and proxy dynamic requests to that from an apache instance that runs the Worker MPM.

This would enable you to scale from a few hundred up to >1000 concurrent connections with a modest amount of memory (4~8GB) when serving a mix of static and dynamic content.

Of course, you should also investigate front-end caching solutions as part of your overall deployment (memcached, varnish).

Alternatively, upgrade to apache 2.4 and its native event MPM, which handles concurrency in a much improved fashion (threads are fired off upon connection, not waiting to be polled.)

3
  • could you expand on the event mpm comment ? How does it stack up vs mpm-worker ?
    – Sirex
    May 11, 2012 at 2:23
  • While the worker MPM was already thread-based, and hence much faster to start and lighter to run, the event MPM no longer polls the socket - it gets notified on activity; therefore, "event".
    – adaptr
    May 11, 2012 at 13:56
  • so it should work better on high traffic (13k/sec) sites ?
    – Sirex
    May 20, 2012 at 20:08
7

It's been about 3 years since the question got posted but I would recommend you go with worker MPM instead of pre-fork even if using PHP, to get the better performance.

As to the differences, pre-fork is non-threaded hence the server forks a process for each client request (it pre-forks in anticipation of new requests so that forking doesn't eat into the response time). Since requests are server in a separate process, this usually taxes your memory and CPU a lot more than. The worker bring multi-threading which is lighter and has better memory utilization.

2

This is something very particular to what you're serving. If you're doing lots of little static connections, threads would be lighter and faster. If you just have few big apps constantly spawned, prefork might have an edge due it's maturity and stability. Why not just set up what you need, test one, swap out the MPM module, try it again, see which one suits you better?

2
  • You can't arbitrarily "swap out" the MPM in apache 2.2; it is set at compile time.
    – adaptr
    Apr 2, 2012 at 13:18
  • You can with apt or RPMs. Debian has several different Apache 2 packages, depending on which style you prefer.
    – SineSwiper
    May 28, 2013 at 3:44
1

that needs on the type and kind of traffic you will have. And also first you need to understand the main difference between the prefork and worker. Hope the below article will help you figure out! http://slashroot.in/how-is-nginx-different-from-apache

2
  • 2
    We prefer answers to have content, not links to content. If you could provide a summary of what's on the link-target, that is best-practice. Link-rot happens.
    – sysadmin1138
    Nov 28, 2012 at 13:09
  • 1
    Question was about Apache (nginx is not apache) and the relative merits of prefork or threads (nginx uses neither)
    – symcbean
    Jun 25, 2014 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .