FrankenPHP压测中P95比平均值更可信，因其揭示95%请求的真实延迟瓶颈，而平均值易被少量快请求拉低失真；需结合P99定位毛刺，并通过X-Request-ID、$upstream_response_time等精准归因。
FrankenPHP压测时，P95响应时间比平均值更能暴露真实瓶颈——它告诉你95%的请求实际卡在哪，而不是被那5%的快请求“平均”掉的问题。
为什么平均响应时间在FrankenPHP里特别不可信
FrankenPHP基于SAPI直连PHP运行时，省去了传统FPM的进程管理开销，但同时也让慢请求更“扎眼”。比如一个请求因OPcache未命中+数据库连接池排队+GC暂停叠加，耗时3.2秒；其余95%请求都在150ms内完成。此时平均值可能只有220ms，看起来很健康，但P95已经飙到3.2秒——而这部分用户大概率已放弃下单或刷新页面。
-
opcache.revalidate_freq设为0时，每个请求都触发文件校验，冷启动阶段P95会剧烈抖动 - FrankenPHP默认启用
php.ini中的max_execution_time，但超时前的阻塞（如DNS解析、TLS握手）不计入该计时，却会计入P95 - 静态资源由FrankenPHP内置HTTP服务器直接服务，而PHP脚本走异步协程调度，两类请求混压时，平均值完全失真
FrankenPHP压测中P95和P99要分开看什么
P95反映的是主流链路稳定性，P99则暴露底层设施毛刺。在FrankenPHP场景下：
- P95突增 → 优先查
php-fpm.conf等效配置项（如pm.max_children是否过小）、Session存储是否用了同步阻塞驱动（如files而非redis） - P99突增 + 错误码
502 Bad Gateway→ 指向FrankenPHP与后端PHP Worker通信超时，需调大frankenphp.worker_timeout - P99突增 +
504 Gateway Timeout→ 说明Worker已响应，但FrankenPHP反向代理层等待过久，检查frankenphp.upstream_keepalive和连接复用状态
怎么在VoltTest或k6里准确采集FrankenPHP的P95
FrankenPHP的HTTP/3支持和QUIC连接复用会让传统工具统计失真，必须确保压测客户端不干扰真实路径：
立即学习“PHP免费学习笔记（深入）”；
- 禁用VoltTest的
--http3开关，改用HTTP/1.1压测，否则P95会被连接建立阶段的QUIC handshake掩盖 - k6脚本里显式设置
userAgent: 'frankenphp-test'，避免被Nginx或CDN缓存拦截，导致P95虚低 - 所有压测请求必须携带
X-Request-ID头，并在FrankenPHP日志中开启log_format记录$request_time和$upstream_response_time，否则无法区分是PHP执行慢还是网络慢
FrankenPHP的轻量不等于简单——它的性能拐点往往藏在OPcache预热曲线、Worker进程生命周期、以及HTTP/3连接复用策略的交界处。P95不是数字，是请求在这些交界处排队的长度。
