Using the Apache Worker MPM vs Prefork on Java App Servers

April 4, 2012 2 By Tad Reeves

After suffering some major performance problems on an Apache system that’s fronting two different Java web apps (via mod_jk and mod_dispatcher) I’m looking into implementing the Worker MPM vs. the stock Prefork MPM that comes on Redhat systems.   Following are my own notes on such, mostly as a personal placeholder.  Hopefully some others have had experience with this.

Why move to Worker?

Per the Apache documentation on multiprocess modules:

The worker MPM uses multiple child processes with many threads each. Each thread handles one connection at a time. Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM.

The prefork MPM uses multiple child processes with one thread each. Each process handles one connection at a time. On many systems, prefork is comparable in speed to worker, but it uses more memory. Prefork’s threadless design has advantages over worker in some situations: it can be used with non-thread-safe third-party modules, and it is easier to debug on platforms with poor thread debugging support.

ref: – Section “Choosing an MPM”

I didn’t find many performance comparisons of prefork vs worker for folks using Apache in front of JBoss or other app servers (mostly just Ruby / PHP / Python) though all reported a higher average throughput (req/sec) with about half the memory utilization.    Very curious how it will perform with our Java apps.

Changes Required on a Redhat (RHEL) System

It looks like the changes that would need to be made, configuration-wise, to implement Worker are as follows:

  • Edit /etc/sysconfig/httpd and uncomment the line that reads “#HTTPD=/usr/sbin/httpd.worker
  • Worker requires a threadsafe version of mod_cgi called which is presently NOT included on our RHEL machines.

Anyone else have performance data or other experience with using the Worker MPM with Tomcat / JBoss / Jetty / Glassfish or with a JCR-type CMS?