Context
A PHP request takes much longer than expected, but the web-server log shows only the final duration. PHP-FPM's slow-log facility can capture a backtrace from a request that exceeds a configured interval. That stack gives a place to investigate; it does not automatically measure every dependency or prove why the request was slow.
Prepare the exact PHP-FPM version, affected pool, request identifier and a controlled reproduction. Determine who may read stack traces, because they can expose code paths and business identifiers. Start in staging where possible and use the smallest pool and collection window that can answer the question.
Configure a bounded observation
- Map the web request to the actual FPM pool and configuration file. Different applications can use separate pools with separate identities and logs. Review the installed binary and service unit before selecting a validation command. A CLI PHP configuration dump does not establish which pool handles the slow web request.
- Inspect
slowlog,request_slowlog_timeoutand supported trace-depth settings in the installed FPM configuration. The upstream sample identifies a slow-log destination when slow-request logging is enabled. Choose the interval from the observed problem and normal request distribution, not from a universal tutorial value. Keep ordinary error logging available as a separate signal. - Confirm that the log destination and trace mechanism work under the pool's deployment model. Filesystem access, container boundaries or process-inspection restrictions can prevent backtrace capture. Review FPM error messages for collection failures rather than concluding that a missing slow-log entry proves the request was fast.
- Validate configuration using the versioned FPM binary's supported test option, then activate through the normal service procedure. Reproduce one harmless slow operation and correlate the captured stack with access-log timing and application request IDs. Keep the raw stack restricted and share a sanitized excerpt with the code owner.
An illustrative lock-wait stack
In an illustrative invoice endpoint, a slow-log backtrace repeatedly stops near a database call. That observation narrows the request's location but does not distinguish database execution from waiting for a connection or a database lock. The next step is to correlate the request with database-side evidence, not immediately add more PHP workers.
| Observation | Additional evidence | Interpretation |
|---|---|---|
| No slow-log entry | Pool, threshold and trace errors | Collection may be misconfigured |
| Repeated dependency frame | Dependency timing and server evidence | Waiting boundary identified |
| Different stacks each capture | Request shape and code path | Multiple causes or sampling points |
| Request continues after trace | Termination policy | Slow logging is observational |
Correct the demonstrated request path
Work with the application owner on the specific dependency, lock or computation indicated by corroborating evidence. Keep slow logging distinct from request_terminate_timeout; terminating requests changes application behavior and can leave side effects that need separate design. A stack-capture threshold is not an application deadline.
Verify the same operation under comparable input and concurrency after the correction. Compare completion time, application correctness and dependency behavior. The absence of new traces is useful only if the collection still works and the representative workload was exercised.
Maintain a tracing SOP
Document pool ownership, safe log location, collection window, retention and the process for removing temporary diagnostics. Monitor trace-write errors and correlate slow requests with business impact. Review whether ongoing sampling is useful after the incident. Clouvenix server performance can help turn a stack snapshot into a focused application investigation.
Technical reference
Upstream FPM pool configuration, PHP FPM directive documentation and FPM feature overview.