The tempting setting
During a WordPress hosting audit, logs showed sites reaching their configured PHP-FPM worker limits. The server also had substantial overall headroom. It would have been easy to connect those two observations and raise the limits immediately.
For one busy site, we held the existing limit while investigating the requests behind the activity. We wanted to understand the workload before giving it more capacity.
What a worker limit actually says
PHP-FPM uses worker processes to handle PHP requests. Its pm.max_children setting limits how many requests a pool can serve simultaneously, as described in the PHP configuration manual.
Reaching that limit tells you the pool has run out of available concurrent capacity at that point. It does not distinguish between useful demand, slow processing, a dependency holding requests open or unwanted traffic.
What we looked at before changing it
We reviewed request patterns, response codes and the routes receiving traffic. The sample included ordinary site requests alongside automated probes and unsuccessful responses.
Some referrers looked suspicious, but those values are supplied by the requester. They did not prove who was responsible. We also identified that the handling of visitor addresses behind the proxy needed checking before using logged addresses to make blocking decisions.
The evidence justified further investigation. It did not justify a confident claim that an attack was the cause of the availability problem.
Why spare memory is not the whole answer
More workers allow more PHP requests to run at once. They do not make an individual slow request finish faster. If the work is waiting on the database, an external service or an expensive operation, additional concurrency may simply put more work onto that same dependency.
WordPress performance needs to be considered across the stack, including hosting, application configuration and caching. The official WordPress optimisation guide describes that broader approach.
When increasing the limit can make sense
A higher limit can be appropriate when there is legitimate concurrent demand and the rest of the system can support it. The useful decision combines workload evidence, request duration, resource use and the effect on other services.
- Identify which requests are occupying the workers.
- Check whether those requests should reach PHP at all.
- Investigate slow dependencies and repeat work.
- Assess the resources needed for additional concurrency.
- Make a controlled change and compare representative traffic.
What happened in this investigation
The busy site’s worker limit was left in place while the request analysis continued. We had not proved a root cause or measured a performance improvement from increasing workers, because that increase was not made.
That is still a useful outcome from an audit: a configuration change deferred until there is a stronger reason to make it. A warning can tell you where to look without telling you what to change.
Let’s look at the evidence.
Tell us what you are seeing and what you want to improve. We can help work out the next useful step.
Explore how we can help ↗