Two warnings turn up in the logs of many busy business websites: Apache's "server reached MaxRequestWorkers setting" and PHP-FPM's "server reached pm.max_children setting". Both mean the same thing: requests are waiting for an available worker. The instinct is to raise the number and move on, but on a server with limited memory that trades slow pages for a server that swaps or runs out of memory at the worst possible moment. Good Apache performance comes from sizing MaxRequestWorkers and PHP-FPM to the RAM you actually have. This guide walks through that calculation for the common modern setup: Apache 2.4 with the event MPM in front of PHP-FPM.

First, confirm which MPM and PHP handler you run

The numbers only make sense once you know the architecture. apachectl -V shows the active MPM on its "Server MPM" line, and on Debian and Ubuntu a2query -M prints just its name. On Red Hat-based systems the service is called httpd, but httpd performance follows the same rules. Then check how PHP runs: through PHP-FPM, usually via proxy_fcgi, or as mod_php inside Apache. The difference is large:

  • prefork with mod_php: every Apache process carries a full PHP interpreter, even when it only sends an image. Memory per connection is high, and MaxRequestWorkers is effectively your PHP limit.
  • Apache event MPM with PHP-FPM: Apache threads are light and handle connections, static files and keep-alive, while PHP runs in a separate pool of processes. Apache can hold many more connections, and PHP-FPM's pm.max_children becomes the setting that protects memory.

If a server still runs prefork with mod_php, moving to event with PHP-FPM is usually the most effective single change. It needs testing, though, because php_value lines in .htaccess files only work with mod_php and have to move to the PHP-FPM pool or a .user.ini file.

Measure Apache memory usage and PHP process size

Sizing starts with measurement during a normal busy period, not on a quiet Sunday morning. Look at:

  • Total RAM and what else lives on the server. A database, a cache such as Redis, mail services and the operating system all need their share before web workers get anything.
  • Average PHP-FPM process size. ps with the rss column, filtered to php-fpm processes, gives a working figure. Use the typical size under load, not the smallest idle process.
  • Apache memory usage per child process. With the event MPM this is usually modest, because the threads inside each child share memory.

Apache mod_status with a server-status page, restricted to your own IP address, shows the scoreboard: how many workers are busy reading, writing or holding keep-alive connections. If most of them sit in keep-alive, the KeepAliveTimeout is holding slots for idle browsers.

Sizing PHP-FPM pm.max_children

For PHP-FPM, the working formula is simple: memory you can give to PHP, divided by the average PHP process size. For example, on a server with 8 GB of RAM where the database, cache and system need about 4 GB, roughly 4 GB remain for PHP. At around 100 MB per process that allows about 40 children, and it is sensible to start a little below that and watch.

Two more settings matter. The process manager mode: dynamic keeps a range of processes ready, ondemand starts them only when needed, which suits many small sites on one server, and static keeps a fixed number, which suits one busy application. And pm.max_requests, which recycles each process after a set number of requests so slow memory leaks in plugins do not build up. Note that the stock pool file shipped with PHP sets pm.max_children to just 5, so a busy site running on defaults hits the limit very early.

Sizing MaxRequestWorkers for the event MPM

With the event MPM, MaxRequestWorkers is the total number of threads that can serve requests at once, and it must fit within ServerLimit multiplied by ThreadsPerChild. Apache's compiled-in defaults are 16 processes of 25 threads, 400 in total, and distribution configuration files often set lower values. Because PHP-FPM already limits the PHP work, MaxRequestWorkers on an event server can sit comfortably above pm.max_children. Extra threads cost little memory and let Apache keep serving images, stylesheets and keep-alive connections while PHP is busy. If you raise MaxRequestWorkers beyond ServerLimit times ThreadsPerChild, raise ServerLimit as well and restart Apache fully, because a graceful reload does not change ServerLimit.

Under the prefork MPM the calculation is stricter: MaxRequestWorkers multiplied by the average Apache process size must fit in the memory left for Apache, since every worker is a complete process.

KeepAlive, timeouts and testing the result

  • KeepAliveTimeout. The default of 5 seconds is reasonable; long values hold slots open for browsers that have already finished. The event MPM handles idle keep-alive connections efficiently, which is another reason to prefer it.
  • Timeout. A very long request timeout lets a few slow or abusive clients occupy workers. Match it to the slowest legitimate request, such as a large upload or report.
  • One change at a time. Apply each change with a graceful reload where possible, watch memory, the scoreboard and response times through a busy period, and keep the previous configuration so you can roll back.

The same measure-first approach applies to any Apache optimization project, and it is how our Apache performance tune-up starts. If pages stay slow while workers sit idle, the bottleneck is elsewhere, usually in database queries or the application itself, which is where MySQL and MariaDB tuning comes in.

Frequently asked questions: maxrequestworkers

Should I just raise MaxRequestWorkers when the warning appears?

Only after checking memory. If the server has headroom, a moderate increase is fine. If it is already close to swapping, a higher limit makes things worse; the answer is fewer, faster requests through caching, or more memory.

How much RAM does a WordPress site need per PHP process?

It varies with plugins and themes, which is why measuring your own processes beats any rule of thumb. Busy stores and page builders tend to need noticeably more per request than simple brochure sites.

Is the event MPM safe with .htaccess files?

Yes. The MPM does not change how rewrite and access rules in .htaccess work. What changes is how PHP runs, so the check is whether PHP settings in those files need to move to the PHP-FPM pool.

Seeing MaxRequestWorkers or pm.max_children warnings on a server in Los Angeles or Long Beach? Our Apache web server optimization service starts with measurement, then tunes the MPM, PHP-FPM, caching and hardening together. Contact us with the warnings from your error log and the amount of RAM in the server.