Worker saturation is a symptom to explain
When Magento requests wait for PHP capacity, customers may see slow pages, stalled checkout or intermittent gateway errors. A message about reaching pm.max_children is useful evidence, but it does not automatically mean the configured limit is wrong. Workers may be occupied by unusually slow requests, blocked dependencies or a traffic pattern the application was not designed to handle.
Midoriweb investigates both demand and request duration. How many requests need PHP, how long do they occupy a worker and what are they waiting for? Increasing concurrency without answering those questions can push more work onto an already constrained database or exhaust memory on the host.
For a wider response-time investigation, see high Magento TTFB. If the site is unavailable, the outage guide helps organise immediate evidence and escalation.
Confirm the serving path and affected pool
Establish how the web server passes requests to PHP and which pool serves the affected website. Shared hosting arrangements may run several sites or pools on one machine. A limit or error observed in one pool should not be assumed to describe every domain on the host.
Record the PHP version, process-manager mode, relevant limits and available host resources through the authorised administrator. Compare these with the deployment and hosting configuration. Do not edit a generated configuration file without understanding whether the hosting panel will overwrite it later.
PHP’s FPM configuration manual defines the process-manager settings. Its status-page documentation describes useful observations and warns that status information should be restricted. Monitoring should not expose request URLs or resource details publicly.
Read active work and queued demand together
Collect worker activity, queued requests and application response times over the same period. A historical maximum is not the same as a current bottleneck. Compare the time at which the limit was reached with the customer-visible errors and the requests being served.
Distinguish a brief burst from sustained saturation. A short spike may be handled acceptably, while a queue that continues growing indicates that incoming work exceeds completion capacity for that period. The business impact depends on waiting time and failures, not merely whether a counter has ever increased.
Use a consistent time zone and note sampling intervals. Charts collected at different resolutions can suggest an order of events that the data does not support. A useful incident timeline aligns the application, web server, database and external dependency observations.
Identify requests that hold workers for too long
Inspect representative slow transactions and their dependency timings. A PHP worker may be occupied while waiting for a database query, search service, remote API or session-related operation. Low CPU usage does not prove spare application capacity if all workers are waiting on something else.
Compare route patterns. Cached public pages, uncached catalogue requests, account activity and checkout can place very different demands on PHP. A campaign driving mostly cacheable landing-page traffic is not equivalent to the same volume of personalised requests or repeated search operations.
Midoriweb would prioritise the requests responsible for the largest relevant workload. The database contention guide and GraphQL performance guide cover two possible branches. The investigation should follow measured execution rather than assume the bottleneck from the URL alone.
Check cache misses and background competition
A cache failure can send more storefront requests through PHP, while background jobs consume CPU, memory or database capacity on the same host. Correlate the incident with cache invalidation, imports, reindexing and deployments. A worker limit that was adequate yesterday may be overwhelmed by a changed workload today.
Our full-page cache diagnosis guide explains how to inspect cache behaviour without compromising customer-specific content. Restoring appropriate caching may reduce demand more effectively than allowing additional simultaneous PHP work.
Background tasks may use separate processes rather than the web pool, but still compete for shared resources. Document that distinction. Counting only web workers can understate the memory and CPU needed when scheduled tasks overlap peak trading.
Size concurrency within the whole system
Any capacity change should consider observed worker memory, available host headroom and downstream limits. Average memory alone may understate the needs of heavier request types. A pool sized as though the entire machine belongs to PHP can leave insufficient resources for the database, search service or operating system.
There is no universal pm.max_children value for Magento. The appropriate setting depends on the architecture, workload and response-time goals. Test the proposed change under representative demand and observe whether throughput improves or whether waiting simply moves to another component.
A temporary increase should be documented with its purpose and review point. If it is only a mitigation while an expensive request is repaired, keep that distinction visible. Otherwise the store can accumulate higher limits without resolving the source of growing resource demand.
Plan recovery without losing the evidence
During a severe incident, a controlled service restart may be operationally necessary, but capture relevant evidence first where feasible. Understand the effect on in-flight requests and customer journeys. A restart that clears the queue does not explain why it formed or establish that the problem will not return.
If a particular job or request pattern is responsible, agree a targeted mitigation. That may involve rescheduling a bulk task, correcting a release or handling an abnormal traffic source through the existing protection process. Do not weaken access controls or disable security features to obtain a superficially faster response.
Record what changed and the expected result. A meaningful recovery check includes customer-facing response, error rate and queue behaviour, not just a successful service status command.
Verify under representative load
Revisit the workflow and traffic pattern that caused saturation. Compare request completion rate, latency distribution, errors, worker occupancy and downstream resource use. A quiet homepage test cannot validate a checkout-capacity problem.
Load tests need an agreed environment and limits. They should not unexpectedly charge cards, send messages or overwhelm a third-party service. Our Magento load-testing guide explains how to define useful scenarios and stop conditions before generating traffic.
Monitor the next real operational peak after release. Document any gap between the test environment and production so the result is not overstated. The objective is stable customer service within a known capacity range, not a single favourable benchmark.
Working with Midoriweb on PHP capacity
Our server management and performance investigation services can connect hosting configuration to actual Magento workloads. Internal worker analysis requires suitable access and should be scoped separately from a public-page assessment.
For an initial brief, include the observed error, affected URLs or actions, timing, traffic context and recent changes. If you have monitoring, provide redacted relevant charts rather than entire logs containing customer information. We would use the evidence to distinguish request optimisation, configuration tuning and genuine infrastructure capacity requirements.
PHP-FPM questions
Does max_children reached mean we need a larger server?
Not necessarily. First establish whether requests are unusually slow or avoidably reaching PHP. Capacity may be needed, but the log message alone does not prove it.
Can low CPU coexist with worker saturation?
Yes. Workers can be occupied waiting on dependencies. Inspect request timing and queue state alongside CPU usage.
Is a restart a permanent fix?
It can restore service temporarily, but the original workload should be investigated and retested. Otherwise the same queue may build again.