Why does serving PHP through the in-process Apache module mod_php effectively pin the server to mpm_prefork, and what changes when the same application moves to php-fpm?

## What mod_php does `mod_php` is the PHP interpreter loaded into httpd as a module. Every httpd child that could serve a PHP request carries the interpreter in its own address space, and a request is executed in-process — no socket, no serialization, no second daemon. That is genuinely fast per request and trivially easy to install, which is why the classic LAMP stack was built this way. The cost is that the interpreter's requirements become the server's requirements. ## Why threading is the problem Under `mpm_worker` or `mpm_event`, one child process runs many request threads in a single address space. Anything living in that space must tolerate concurrent execution: no unguarded global mutable state, no static buffers reused across calls. PHP can be built in a thread-safe configuration, but the packages distributions ship for use with a web server are generally the non-thread-safe build, and even where the core is safe, the long tail of third-party C extensions is where the guarantees fall apart. A single extension with a static buffer is enough. And the failure mode is not a clean refusal to start. It is intermittent corruption under concurrency: responses containing another request's data, sporadic segfaults that take down every thread in that child, bugs that vanish when you attach a debugger. This is why the guidance has always been categorical — if you load an in-process interpreter, run `mpm_prefork`, where each child is single-threaded and concurrency inside the address space never happens. ## What prefork then costs you Once you are pinned to prefork, the whole MPM cost model applies at its worst: - Concurrency equals process count. Serving 300 simultaneous connections means 300 processes. - Each process carries an interpreter, its loaded extensions, and its per-request memory, so resident size per child is typically an order of magnitude larger than a bare httpd child. Multiply by the concurrency ceiling and the ceiling that fits in RAM is far lower than people expect. - You lose the event MPM's handling of idle keep-alive connections. A browser holding a connection open between requests occupies a full PHP-carrying process for the whole `KeepAliveTimeout`. - Every connection is equally expensive regardless of what it asks for. A request for a small static image occupies exactly the same interpreter-laden process as a request that runs application code. Teams usually discover this as a memory ceiling: `MaxRequestWorkers` cannot be raised because the box would swap, so the site saturates at a concurrency far below what the CPU could handle. ## What php-fpm changes php-fpm runs PHP as a separate daemon with its own pool of worker processes, and httpd forwards PHP requests to it over FastCGI — mechanically, through `mod_proxy_fcgi`. The interpreter is no longer inside httpd, so: - httpd can run `mpm_event`. The web tier gets threaded workers and asynchronous handling of idle keep-alive connections; a connection sitting between requests no longer costs a PHP process, and a connection asking for a static file never touches PHP at all. - The two tiers are sized independently. The PHP pool has its own worker-count setting (`pm.max_children`), which is where you apply your memory arithmetic — that number times per-process PHP memory. The httpd side can be sized for connections rather than for interpreters, which are very different quantities. - Isolation improves. PHP can run as a different user than the web server, pools can be separated per site, and a PHP restart to pick up new code does not require restarting httpd or dropping connections. - You gain a queue with a defined boundary. When the PHP pool is full, requests wait for a PHP worker while httpd keeps serving everything else — instead of the entire web tier being the queue. The trade is real, not free: you now run and monitor two daemons, requests cross a socket, and you have a second saturation point to understand. But the shape is strictly better for anything that mixes static and dynamic content or runs meaningful concurrency, and it is why modern distributions and modern deployment guides default to the php-fpm arrangement rather than the in-process module. ## The interview point The question is really about a general principle with a famous instance: embedding a language runtime inside your web server couples the server's concurrency model to the runtime's thread-safety. When you decouple them, each tier gets to use the concurrency model that suits it. The same reasoning explains why application servers are generally reached over a protocol rather than loaded into the proxy in front of them.