CODEWITHSUNDEEP
apacheeventsconcurrencyworkerapache2.4
user636044
user636044

Reputation:

Why shouldn't you always use Apache's event MPM instead of the worker MPM?

mpm_event is like mpm_worker except that mpm_event manages all (non-SSL) KeepAlive connections with a separate, dedicated thread rather than having each thread manage each individual connection. By giving and then keeping a dedicated thread for each KeepAlive connection, mpm_worker leaves that thread and its resources bound to that connection regardless of whether or not a request is being processed. mpm_event on the other hand, can lower system resource use in high concurrency environments by allowing the thread and its resources to be recycled back to the system once requests are complete.

It seems to me that in high concurrency, non-SSL environments where KeepAlive has long timeouts, mpm_event has the potential to make for a system that can handle a higher workload with equivalent resources than a system with the same resorces using mpm_worker. More importantly, it seems to me that in terms of resource use and features, mpm_event is at least as good as mpm_worker, if not better, in all circumstances.

Despite my understanding that mpm_event is always at least as good and possibly better, my favorite Linux distributions default to using mpm_worker when installing Apache 2.4 from the repositories. This makes me wonder if my thinking is incomplete and if there is some technical reason I am missing to use mpm_worker rather than mpm_event in Apache 2.4.

My question therefore is am I correct in saying mpm_worker is at least as good as mpm_event, if not better, in all circumstances, and (2) if not, what technical benefits are there to using mpm_worker in Apache 2.4?

Upvotes: 7

Views: 2558

Answers (1)

covener
covener

Reputation: 17872

There are two "advantages" I can think of. Both are pretty obscure.

worker does not need to fight over a lock in each process to protect the list of keepalive connections. This means there are degenerate workloads that could see that lock contention at relatively low # of total clients and thus not benefit at all from the scalability of event.

secondly, some very obscure third-party modules might have subtle bugs under event in cases where things like async write completion means some callbacks happen on a "different" thread. async write completion is what happens when a write to the client would block (client reading slowly) so the request is suspended and will be brought back to life on a new thread when the client socket is again writable.

Upvotes: 3

Related Questions