Switch Apache MPM to event in cPanel

The Apache MPM (multi-processing module) decides how Apache handles connections. Many cPanel servers still run prefork, which uses one full process per connection. The event MPM uses threads and handles idle keep-alive connections cheaply, so it serves more visitors with less memory. This guide explains the choice, the PHP-FPM requirement, and how to switch and tune safely.

Before you start

• Root access to WHM and SSH.
• A backup EasyApache profile, so you can roll back. See the EasyApache 4 guide.
• All sites on PHP-FPM, or a plan to move them. The reason is below.

Prefork, worker and event

• prefork: one process per connection, no threads. It is the safest choice for old, non-thread-safe modules, but it uses the most memory.
• worker: several threads in each process. Much lighter than prefork.
• event: like worker, but a separate listener thread handles idle keep-alive connections, so worker threads are not tied up waiting. It is the usual choice for modern Apache, and it is needed for good HTTP/2 performance.

Why PHP-FPM is required

PHP loaded inside Apache as a module (the DSO or mod_php style handler) is not safe in threaded MPMs. With event, PHP must run outside Apache, and on cPanel that means PHP-FPM.

Check which handler each domain uses in WHM » Software » MultiPHP Manager. Turn on PHP-FPM for every domain before you switch, then load each site to confirm it works. See enable and tune PHP-FPM in cPanel.

Switch to event in EasyApache 4

1. Save a backup profile:

   /usr/local/bin/ea_current_to_profile --output=/etc/cpanel/ea4/profiles/custom/before-mpm-event.json

1. In WHM, open Software » EasyApache 4 and click Customize.
2. Open the Apache MPM tab and select mod_mpm_event. Only one MPM can be installed, so prefork is removed.
3. EasyApache may list modules it has to remove because they need prefork. Note them.
4. Go to Review and click Provision.

Apache restarts with the new MPM.

Tune MaxRequestWorkers

With event, capacity is threads, not processes:

• MaxRequestWorkers is the total number of simultaneous requests Apache serves.
• ThreadsPerChild is the threads in each process.
• ServerLimit caps the number of processes. MaxRequestWorkers cannot be more than ServerLimit × ThreadsPerChild.

Threads are cheap, but each active request still sends work to PHP-FPM. There is no point letting Apache accept far more PHP requests than your PHP-FPM pools can run. Start modestly, for example:

<IfModule mpm_event_module>
    ServerLimit          16
    ThreadsPerChild      25
    MaxRequestWorkers    400
</IfModule>

Set Max Request Workers and Server Limit in WHM » Service Configuration » Apache Configuration » Global Configuration. If a directive such as ThreadsPerChild has no field there, add it through Include Editor in the Pre Main Include for all versions. The Apache Global Configuration guide covers both screens.

Check it works

Confirm the running MPM and syntax:

/usr/sbin/httpd -V | grep -i mpm
/usr/sbin/httpd -t

Expected output includes:

Server MPM:     event
Syntax OK

Then load each site and test a form or login. In WHM » Server Status » Apache Status, you should see many slots shown as waiting threads rather than full processes.

Troubleshooting

• Apache will not start after the switch: a custom include uses a directive from a removed module. Run /usr/sbin/httpd -t to find the line, fix it, then restart.
• Sites show PHP source code or download PHP files: the domain was still on a DSO handler. Turn on PHP-FPM for it in MultiPHP Manager.
• "server reached MaxRequestWorkers" in the error log: raise MaxRequestWorkers in small steps and check that PHP-FPM pools are not the real bottleneck.
• Something critical broke: provision your saved before-mpm-event.json profile to return to prefork, then investigate.

Next steps

• Size PHP pools to match Apache: PHP-FPM in cPanel.
• Watch load after the change: check server status and load in WHM.