292

This is a Canonical Question about selecting the right Apache httpd MPM.

I'm a little confused between the different MPMs offered by Apache - 'worker', 'event', 'prefork', etc.

What are the major differences between them, and how can I decide which one will be best for a given deployment?

HBruijn
  • 72,524
  • 21
  • 127
  • 192
Tiffany Walker
  • 6,541
  • 13
  • 53
  • 77
  • 5
    If you are supporting mod_php, then you are doing prefork. – Zoredache Apr 26 '12 at 20:29
  • 6
    @Zoredache: ? she never mentioned PHP, and even if she had, mod_php would only rule out event. Or are you still clinging to a remark made by RL 8 years ago? Last bug logged in PHP related to threaded apache was in 2005. – symcbean Apr 26 '12 at 22:24
  • 2
    Sorry - got to vote to close this - is far too broad a questionto answer here. – symcbean Apr 26 '12 at 22:25
  • 1
    @symcbean Re: PHP and Threads - PHP's core is threadsafe these days but lots of other stuff you'll find people compiling in isn't. I've been bitten as recently as last year, so it's very much a "test (extensively) before relying on it in production" situation still... – voretaq7 Apr 27 '12 at 03:19
  • Depending on the OS you're using you may not even have all those options available with a standard install. – John Gardeniers Apr 27 '12 at 03:56

4 Answers4

450

There are a number of MPM modules (Multi-Processing Modules), but by far the most widely used (at least on *nix platforms) are the three main ones: prefork, worker, and event. Essentially, they represent the evolution of the Apache web server, and the different ways that the server has been built to handle HTTP requests within the computing constraints of the time over its long (in software terms) history.

prefork

mpm_prefork is.. well.. it's compatible with everything. It spins off a number of child processes for serving requests, and the child processes only serve one request at a time. Because it's got the server process sitting there, ready for action, and not needing to deal with thread marshaling, it's actually faster than the more modern threaded MPMs when you're only dealing with a single request at a time - but concurrent requests suffer, since they're made to wait in line until a server process is free. Additionally, attempting to scale up in the count of prefork child processes, you'll easily suck down some serious RAM.

It's probably not advisable to use prefork unless you need a module that's not thread safe.

Use if: You need modules that break when threads are used, like mod_php. Even then, consider using FastCGI and php-fpm.

Don't use if: Your modules won't break in threading.

worker

mpm_worker uses threading - which is a big help for concurrency. Worker spins off some child processes, which in turn spin off child threads; similar to prefork, some spare threads are kept ready if possible, to service incoming connections. This approach is much kinder on RAM, since the thread count doesn't have a direct bearing on memory use like the server count does in prefork. It also handles concurrency much more easily, since the connections just need to wait for a free thread (which is usually available) instead of a spare server in prefork.

Use if: You're on Apache 2.2, or 2.4 and you're running primarily SSL.

Don't use if: You really can't go wrong, unless you need prefork for compatibility.

However, note that the treads are attached to connections and not requests - which means that a keep-alive connection always keeps a hold of a thread until it's closed (which can be a long time, depending on your configuration). Which is why we have..

event

mpm_event is very similar to worker, structurally; it's just been moved from 'experimental' to 'stable' status in Apache 2.4. The big difference is that it uses a dedicated thread to deal with the kept-alive connections, and hands requests down to child threads only when a request has actually been made (allowing those threads to free back up immediately after the request is completed). This is great for concurrency of clients that aren't necessarily all active at a time, but make occasional requests, and when the clients might have a long keep-alive timeout.

The exception here is with SSL connections; in that case, it behaves identically to worker (gluing a given connection to a given thread until the connection closes).

Use if: You're on Apache 2.4 and like threads, but you don't like having threads waiting for idle connections. Everyone likes threads!

Don't use if: You're not on Apache 2.4, or you need prefork for compatibility.

In today's world of slowloris, AJAX, and browsers that like to multiplex 6 TCP connections (with keep-alive, of course) to your server, concurrency is an important factor in making your server scale and scale well. Apache's history has tied it down in this regard, and while it's really still not up to par with the likes of nginx or lighttpd in terms of resource usage or scale, it's clear that the development team is working toward building a web server that's still relevant in today's high-request-concurrency world.

Anthony Geoghegan
  • 2,800
  • 1
  • 23
  • 34
Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 3
    -1: IME, worker only reduces the size of the httpd footprint by in the region of 15% (IIRC Linux reports COW in RSS which makes pre-fork look as if it using much more memory than it does). There's negligible difference between the kernel footprint for a process and an NPTL thread. It's a long way from earth-shattering. I don't understand why you think that waiting for and allocating a thread is more efficient in scheduling terms than waiting for / scheduling a (pre-forked) process. Nor what bearing you think SSL has on the whole she-bang. – symcbean Apr 27 '12 at 08:28
  • 11
    @symcbean So you're saying that 15% RAM usage isn't significant? That's fine, but my opinion would be otherwise. Concurrency performance claims are not my own. See [here](http://people.apache.org/~jim/presos/ACNA11/Apache_httpd_cloud.pdf). And the SSL difference is spelled out plainly in the documentation for the event MPM: `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.` – Shane Madden Apr 27 '12 at 16:23
  • 4
    @ShaneMadden ` and while it's really still not up to par with the likes of nginx or lighttpd in terms of resource usage or scale` I've had apache floor both of those systems. – Kelly Elton Jul 05 '12 at 17:05
  • @ShaneMadden in regard to the problem with SSL and the event MPM: Do you know if nginx handles this significantly better than apache? – DASKAjA Jul 02 '13 at 09:37
  • It seems that if you compile apache 2.4 without knowing about mpm modules it comes with module named event mpm module and it works with mod_php7 (right now I m researching mpm because apache2.4 is exceeding mysql connection limit while apache 2.2 with same mysql server is not) – BioHazard Jan 08 '16 at 11:16
  • I wonder, where to find compiled Apache for Windows with mpm_prefork mode. Currently I have some issues with getenv/putenv variables in PHP -they get messed up because of single-process but I'd like to have each request in a separate process. – JustAMartin Feb 03 '16 at 16:44
  • "gluing a given connection to a given thread until the connection closes" -- more like gluing a given thread to the connection. It's the fact the thread can't do anything else until the connection closes which is the problem. – aaa90210 Jun 27 '16 at 04:25
  • Hello, so if am using FastCGI and php-fpm, which MPM do I use? – David Okwii Dec 09 '16 at 05:37
  • 1
    @DavidOkwii `mpm_event` is the _mod du jour_. But on Apache 2.4.24 or newer. Older than that, use `mpm_worker`. – pepoluan Apr 27 '17 at 18:31
  • 5
    The limitation of the `event` MPM when using SSL connections does no longer appear to be true. The manual https://httpd.apache.org/docs/2.4/mod/event.html now says: "These improvements are valid for both HTTP/HTTPS connections." Thus, on Apache 2.4, `event` now appears to be always advisable, while `worker` is still there from 2.2 times. – Peter Thomassen Aug 25 '17 at 15:43
  • Why is `worker` best for SSL? – Geremia Mar 12 '18 at 03:53
14

Here is a good explanation of how it works with gifs:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Briefly: if you on 2.4 and you need httpd as a reverse proxy (dispatcher) so your choice is an Event MPM

Yura
  • 291
  • 2
  • 3
  • Even if we use SSL ? I use apache as a proxy and SSL enabler on a non SSL website. – bokan Jan 14 '19 at 15:12
  • @bokan looks like yes, this is the best, but anyway proxying is limited for SSL – Yura Jan 16 '19 at 12:31
  • Wow~ The blog post is way better than the accepted answer, and the gifs are wonderful ! Thankssss. You saved my day. – Rick Jun 08 '19 at 10:18
9

As of February 2018, the Apache 2.4 documentation for Event MPM states that using Apache as a proxy will keep the "improved connection handling" since 2.4.24 from working as designed. See the Limitations section.

The issue is that, as a proxy, the worker cannot tell where the end of the response is, and will be forced to wait until the entire response is seen before returning control to the listener.

For this reason, it seems that using the Worker model may be best for when apache is used as a proxy. It is not really clear to me if there are advantages to the event model in a proxy environment, but perhaps there are.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
AndOr
  • 113
  • 1
  • 5
6

Mostly depends on which Apache modules you want to use. I think worker is generally the default choice, but some (older) modules require forking and depend on prefork.

If you have no preferences, I recommend you go with the preferred dependency from your OS distribution. Ubuntu for example will by default install mpm-worker when you install Apache2.

Jeroen Ooms
  • 2,187
  • 7
  • 32
  • 51