fix(prof) FrankenPHP idle phase#3169
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3169 +/- ##
============================================
- Coverage 79.09% 79.07% -0.02%
Complexity 2890 2890
============================================
Files 114 114
Lines 11443 11443
============================================
- Hits 9051 9049 -2
- Misses 2392 2394 +2
Flags with carried forward coverage won't be shown. Click here to find out more. see 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Benchmarks [ profiler ]Benchmark execution time: 2025-04-01 11:49:31 Comparing candidate commit f23afb5 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 29 metrics, 7 unstable metrics. |
Description
This PR fixes FrankenPHP idle phase detection in worker mode. Turns out, that
frankenphp_handle_request()does also execute the closure given to it, so the current way of measuring the idle phase in worker mode is incorrect. So what I am doing now instead of hookingfrankenphp_handle_request()is hooking intosapi_module.activate/sapi_module.deactivatein case the detected SAPI is FrankenPHP. If one of those functions is being called whilefrankenphp_handle_request()is the current execute frame, we are indeed in the idle phase.Why does this work?
FrankenPHP in
frankenphp_worker_request_shutdown()calls intosapi_deactivate()and infrankenphp_worker_request_startup()it calls intosapi_activate().There is also a small cleanup: I have extracted the idle phase start and stop code into their own functions.
Reviewer checklist