php接口压力测试配合xdebug profiling分析教程-php教程-PHP中文网

压力测试与xdebug profiling必须分离：先用ab/wrk压测定位瓶颈，再单请求触发profiling分析；混用会导致性能失真、结果误导。

php接口压力测试配合xdebug profiling分析教程

压力测试和 Xdebug Profiling 不能混着用——压测时开 profiling 会拖垮服务，profiling 本身也不适合高并发场景。真要定位接口瓶颈，得先压、再分析，分两步走。

别用 PHP 脚本写并发请求，那测的是你脚本的调度能力，不是接口的真实承载力。ab 和 wrk 是轻量、可靠、结果可比的标准工具。

ab -n 1000 -c 100 http://localhost/api/user：100 并发、共 1000 次请求，看 QPS 和失败率
看到 502 Bad Gateway 或大量超时？先停压测，查 php-fpm.status 和 systemctl status php-fpm，确认是不是 worker 耗尽或被 OOM kill
压测前必须调优后端资源：MySQL max_connections、PHP-FPM pm.max_children、Redis 连接池大小，否则 ab 报的“慢”只是配置瓶颈
wrk 支持 POST JSON：wrk -t4 -c100 -d10s -s post.lua http://localhost/api，post.lua 里写好 header 和 body

Xdebug Profiler 只能对单个请求采样，且开启后每个请求 CPU 和 I/O 开销剧增。压测中开着它，结果既不准又误导。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

确保 xdebug.mode=profile 且 xdebug.start_with_request=trigger，否则 Web 请求不会生成 profile 文件
浏览器访问加 ?XDEBUG_PROFILE=1，或 curl 带 Cookie：curl -H "Cookie: XDEBUG_PROFILE=1" http://localhost/api/user
检查 xdebug.output_dir 目录权限，比如 /tmp/xdebug 必须能让 Web Server 进程（如 www-data）写入，sudo chown -R www-data:www-data /tmp/xdebug 比 chmod 777 安全
生成的 cachegrind.out.* 文件不能双击打开——PhpStorm 默认不识别，必须走 Tools → Analyze Xdebug Profiler Snapshot

Flat View 只告诉你哪个函数耗时长，Call Tree 才揭示为什么长。真正卡点往往藏在子调用里。

切换到 Call Tree 视图，展开顶层入口（如 index.php 或 Router::dispatch），逐层下钻
对比 Inclusive Time 和 Exclusive Time：如果 UserService::getById() 的 Inclusive 很高但 Exclusive 很低，说明慢在它调用的 PDO::query() 或缓存读取
注意 Calls 列：一个 array_merge() 耗时 0.2ms，但如果被调了 800 次，总耗时就占了 160ms，这种高频小函数容易被忽略
数据库查询只显示 PDO::query() 耗时，不显示 SQL 执行计划——想查慢查询，得配合 MySQL 的 slow_query_log 或 EXPLAIN

配完 profiling 却没生成文件，90% 是配置没落到实际运行的 php.ini 上，而不是 PhpStorm 界面没反应。

在页面里输出 phpinfo()，搜索 Loaded Configuration File，这才是 Web 请求真正加载的配置路径
CLI 和 Web 使用不同 php.ini：PhpStorm 里 Ctrl+Alt+S → PHP → CLI Interpreter → Configuration file 显示的是 CLI 路径，和 Web 无关
xdebug.mode=profile,debug 是合法的，但 debug 会额外启动调试通道，可能冲突；压测分析阶段建议只开 profile
生成的 cachegrind.out.* 文件时间戳和请求时间对不上？检查服务器时区是否和 PHP date.timezone 一致，否则文件名里的 %t 会错乱