The Bizarre Daily Server Crash
Recently, I was working on a project where the client was facing a bizarre issue: their server ran perfectly fine most of the day, but every single afternoon, it completely hung. The only way to fix it was a hard server restart, after which everything went back to normal. Because of this, they were forced to manually restart their server every single afternoon.
The "Hacker" Misconception
When they first contacted me, they were convinced it was a security breach. They suspected that an exposed API or an open database connection was allowing a hacker to steal or collect their data every afternoon. It was a funny theory—why would a data thief operate strictly on a 9-to-5 afternoon schedule, and why would a simple server restart magically make them stop?
The Exhaustive Diagnostics
Initially, I didn't fully understand the root cause either. I spent almost half a month optimizing the database, refactoring schemas, adding indexes, and cleaning up the code, but nothing worked. The server kept crashing every afternoon.
Uncovering the Flaw in mod_php
That is when I uncovered a major architectural flaw regarding how mod_php handles requests. When a server uses mod_php, the PHP interpreter is bundled directly inside the Apache web server processes. This means every single request—whether it is for a dynamic PHP script or a completely static asset like a .txt, .css, or .js file—is handled by a heavy Apache process containing the full PHP engine.
The Resource Drain from Static Files
For example, if your website's index page links to 10 JavaScript files and 10 CSS files, a browser rendering that page will request all 20 of those static files simultaneously. Under mod_php, Apache maps those requests to 20 processes that have the entire PHP engine loaded into memory, wasting massive system resources just to perform basic file I/O. For static files, PHP plays absolutely no role, yet it still consumes RAM.
The Afternoon Traffic Spike Crash
When afternoon traffic naturally spiked, hundreds of users requested these pages and assets at the same time. Apache rapidly spawned copies of these heavy, bloated processes to handle the load, which instantly drained the server's remaining RAM, pushed it into swap memory, and froze the entire machine.
The Solution: Migrating to PHP-FPM
To resolve this, I migrated the server configuration from mod_php to PHP-FPM. The issue disappeared completely without requiring any upgrades to the underlying PHP version (the client was running PHP 7.0 at the time).
How PHP-FPM and FastCGI Fixed the Crisis
With PHP-FPM, Apache and PHP operate as entirely separate entities. They communicate over a lightweight protocol called FastCGI. Now, when a request comes in, Apache checks the file extension. If it is not a .php file, Apache serves the static asset directly using an ultra-lightweight process (around 5 to 10 MB), completely bypassing PHP.
Efficient Process Management
If it is a .php file, Apache hands the request off to the PHP-FPM Master Process. The Master Process acts as a manager, permanently running in the background and overseeing a pool of standby worker processes. It simply assigns the task to an idle worker in the pool, processes the code, and passes it back.
The Final Verdict:
By isolating the two environments, static file requests no longer bloat the server's memory. The afternoon crashes weren't caused by a hacker at all; they were simply the result of daily peak traffic windows overloading an inefficient mod_php architecture.