必须用wrk或ab模拟真实并发以暴露PHP框架瓶颈，wrk因支持长连接和HTTP/2更准确；ab受限于HTTP/1.1且不复用连接，易误判；压测需关注QPS、p99延迟及FPM慢日志等关键指标。
要准确评估PHP框架在真实流量下的响应能力，必须用wrk或ab模拟出贴近生产环境的并发请求模式，而不是只看单次请求耗时——后者无法暴露连接池打满、FPM子进程阻塞、OPcache未预热等关键瓶颈。
安装wrk和ab工具
先确认系统已安装curl和build-essential：sudo apt-get update && sudo apt-get install -y curl build-essential。
安装wrk：sudo apt-get install -y wrk。Ubuntu 22.04+默认源已包含，无需编译。
安装ab：sudo apt-get install -y apache2-utils。注意ab不支持HTTPS SNI扩展，压测带多个域名的HTTPS站点会失败。
立即学习“PHP免费学习笔记（深入）”；
【ab无法测试HTTP/2接口】——它只走HTTP/1.1协议栈，若你的PHP框架已启用HTTP/2（如通过Nginx+ALPN），ab的结果将严重失真，必须换wrk。
wrk压测PHP接口的正确姿势
wrk比ab更适合压测现代PHP服务，因为它用多线程+异步I/O，能维持长连接、复用TCP通道，更真实反映FPM或Swoole的负载特征。
第一步：用-t参数匹配CPU核心数，避免线程调度争抢。例如4核服务器：wrk -t4 -c400 -d30s --latency http://localhost/api/user。
第二步：-c（并发连接数）应远大于-t，比如-t 4配-c 400，模拟4个线程共维护400个活跃连接——这才能压出FPM max_children配置的真实瓶颈。
第三步：加--latency开关，输出p90/p99延迟，而非仅平均值；高延迟毛刺往往藏在尾部，平均值会掩盖问题。
第四步：若接口需鉴权，写一个auth.lua脚本注入动态Token，避免所有请求被缓存命中，导致QPS虚高。
ab压测的典型误用与修正
方法一：基础压测命令必须带-n和-c两个参数，缺一不可。ab -n 1000 -c 100 http://test.local/index.php 表示发1000次请求，每批最多100个并发。
方法二：禁止用-ab -n 100 -c 1000这种“单批千并发”写法。ab本质是单线程阻塞模型，-c 1000会让本地socket端口快速耗尽，触发大量TIME_WAIT，结果全是connect timeout错误，不是服务端的问题。
方法三：压测前清空OPcache：php -r "opcache_reset();"。否则首次请求慢、后续飞快，测不出冷启动性能。
【ab默认不复用连接】——每个请求都新建TCP连接，这会放大Nginx或PHP-FPM的accept队列压力，测出来的错误率偏高，不代表真实用户行为。
解读压测结果的关键指标
看wrk输出时，重点盯住Requests/sec（QPS）、Latency Distribution里的p99值、以及Transfer/sec是否接近网络带宽上限。
ab结果中，Failed requests > 0时，先检查Connection refused还是Timeout——前者说明FPM子进程全忙，后者可能是Nginx proxy_read_timeout太短。
当QPS不再随-c线性增长，且p99延迟陡升，说明已触达PHP-FPM的max_children硬限，此时必须调大pm.max_children或改用ondemand模式。
内存占用飙升但CPU不高？大概率是OPcache未启用或realpath_cache_size过小，导致每次include都重复解析路径。
压测后必须做的三件事
第一件事：立刻查PHP-FPM slow log。在www.conf里开slowlog = /var/log/php-fpm-slow.log，request_slowlog_timeout = 1s，压测后grep "script"就能定位超时脚本。
第二件事：用top -H观察各fpm worker线程的CPU占比，若某个worker长期100%，说明该进程内有死循环或阻塞IO未设timeout。
第三件事：运行sudo strace -p $(pgrep -f "php-fpm: pool www") -e trace=epoll_wait,accept,read,write -s 100 -o fpm.strace.log，抓取实际系统调用瓶颈。
