A surprising amount of what gets labelled as PHP performance work is actually configuration work that was simply pushed into the backlog.
Without OPcache enabled and properly sized, PHP recompiles every script on every request. This adds a fixed cost to every page load, regardless of how efficient the application logic is.
The first settings to verify are the cache memory allocation and the maximum number of cached files. If the memory allocation is too small, OPcache will continually evict and recompile scripts under actual traffic. Likewise, if the file limit is too low for a large codebase containing thousands of files, PHP will encounter the same issue for a different reason.
These settings are easy to overlook because many installations retain their default values, which are often intended for small test applications rather than production workloads.
By default, PHP checks whether a file has changed on every request. While each check is small, the filesystem overhead accumulates under heavy traffic.
In production environments, code changes only occur during deployments, making these checks unnecessary. Disabling timestamp validation and explicitly clearing OPcache during each deployment is the standard approach we now use.
However, this also means the deployment process must reliably clear the cache. Otherwise, developers can spend a frustrating amount of time wondering why their changes are not appearing.
PHP-FPM worker settings determine how many requests an application can process concurrently before requests begin to queue.
Parameters such as the process manager mode, maximum worker count, startup workers, spare workers, and worker recycling behaviour have a direct impact on throughput.
If the worker count is too low, incoming requests will queue under load. From the outside, this often appears as though "the application is slow", even when individual requests execute quickly. The actual bottleneck is simply a shortage of available workers.
Each PHP-FPM worker consumes memory based on the application's peak usage, not its average usage.
Configuring worker counts without first measuring actual memory consumption is a common cause of out-of-memory failures during traffic spikes that the server should otherwise be able to handle.
We now measure worker memory usage under realistic load conditions before deciding how many workers can run simultaneously, never the other way around.
Running PHP directly inside the web server versus running it as a separate pool of PHP-FPM workers is not simply a matter of preference.
A separate worker pool provides several advantages:
For high-traffic applications that still run PHP directly inside the web server, we have found that migrating to a separate PHP-FPM architecture is almost always worth the effort.
Maybeach Tech tunes and runs production PHP systems for high traffic applications. Get in touch and let us review your setup.
