On this page
Apache HTTP Server has several Multi-Processing Modules (MPMs), and the choice affects how connections are handled. PHP-FPM is a separate process manager that has its own worker limits. A server can be overloaded even when one side appears idle if Apache admits more concurrent requests than PHP-FPM can serve. This guide explains what to measure before adjusting capacity on Apache 2.4 and PHP-FPM. Commands are read-only examples for authorized Linux hosts; exact module and pool names vary.
Prerequisites and topology
Identify whether Apache serves PHP through PHP-FPM and mod_proxy_fcgi, a legacy embedded PHP module, or another gateway. Record the Apache version, loaded MPM, PHP-FPM pool configuration, memory limit and reverse proxy or CDN in front. Do not apply MPM advice meant for PHP-FPM to an embedded-PHP deployment without checking module compatibility. Capture a baseline of response time, active workers, memory and 5xx responses during representative traffic.
apachectl -v
apachectl -M | grep -E 'mpm_|proxy_fcgi|php'
php-fpm -v
The PHP-FPM binary may have a versioned name such as php-fpm8.2, or the service may be containerized. Use the actual binary and unit on your host. apachectl -M can reveal module configuration but does not prove a particular vhost routes to PHP-FPM; inspect the relevant handler and proxy configuration too.
Understand the concurrency models
Apache's prefork uses separate processes with one thread per process. worker uses multiple threads in multiple child processes. event is also threaded and is designed to handle certain connection states more efficiently. Only one MPM is active at a time. The best choice depends on modules, operating system and workload; there is no universal “fastest” setting. A legacy module with thread-safety constraints may limit which MPM can be used safely.
The MaxRequestWorkers directive limits simultaneous requests that Apache can serve. A larger value is not automatically better: each active request can consume memory and place load on PHP-FPM and the database. Conversely, a value that is too low can cause queuing under legitimate peaks. Review Apache status and logs alongside actual memory pressure before tuning. Do not copy another company's worker count without measuring your own server.
Measure PHP-FPM separately
PHP-FPM pools have their own process manager settings and per-process memory footprint. A PHP request blocked on a slow database can occupy a worker even while CPU usage is low. Count workers, inspect memory use and note request duration under a controlled representative load. If PHP-FPM reaches its process limit, Apache can return upstream errors or queue requests depending on configuration. Raising the limit without enough RAM can cause swapping or OOM kills.
ps -eo pid,rss,comm | grep -E 'php-fpm|httpd|apache2'
free -h
ss -ltn
These commands offer a snapshot, not a statistical capacity model. Memory RSS includes shared pages in ways that can overstate total usage when summed. Compare peak process counts, proportional memory where available, and system memory pressure over time. Use PHP-FPM's status facility only if it can be exposed safely to an internal monitoring path; never publish it unauthenticated on the internet.
Stage one change and validate
Review the relevant Apache MPM and PHP-FPM settings together. Estimate a safe upper bound from actual memory headroom and workload behavior, then test in staging. Change one limit at a time, validate syntax, reload the specific service through a documented procedure and observe customer routes. A graceful reload may still affect long-running requests; schedule production changes appropriately.
Record the old configuration and a rollback plan. Test a representative mix of static assets, PHP pages, authentication and uploads. Watch p95 response time, 5xx errors, Apache busy workers, PHP-FPM active/idle processes, database load and swap. If the bottleneck moves from PHP-FPM to the database after a limit increase, revert or reduce concurrency rather than claiming a tuning success.
Troubleshooting and security
If Apache reports full workers, determine whether slow clients, long-lived connections or backend requests dominate. If PHP-FPM is full, inspect slow logs and database timing before adding processes. If a 502 appears, check the upstream socket path, permissions and FPM service status; capacity is only one possible cause. Keep PHP-FPM pools isolated by application and tenant where appropriate. Do not solve a permission error by running a pool as root.
FAQ: Should I always use event? No; verify module compatibility and real workload behavior first. FAQ: Does raising MaxRequestWorkers guarantee higher throughput? No; it can overload the backend. Expected result: a measured configuration with enough headroom, predictable queueing and stable customer response times.
Related reading: Apache versus Nginx and Nginx/PHP-FPM 502 diagnosis. East4Serv server operations can help profile a production stack.
Primary references: https://httpd.apache.org/docs/current/mpm.html and https://httpd.apache.org/docs/2.4/en/mod/mod_proxy_fcgi.html and https://httpd.apache.org/docs/2.4/en/misc/perf-tuning.html.