真正靠谱的压测是ssh登录后用ab命令：ab -n 1000 -c 200 https://your-site.com/api/user；需装apache bench并软链，禁用- k参数，关注failed requests、write errors和time per request三指标。

用 Apache Bench 直接测，别信面板里那个“/bench”入口

宝塔面板在网站配置里加了 /bench 路由，表面是给你点点鼠标就能压测，实际它调用的是一个极简前端界面，背后没做并发隔离、没控制连接复用、不支持参数化，测出来的 QPS 偏高且不可复现，尤其对 HTTPS 或带 Cookie 的接口完全失真。

• 真正靠谱的做法是 SSH 登录后直接用 ab：比如 ab -n 1000 -c 200 https://your-site.com/api/user（注意必须加 https://，否则会走 HTTP 而触发重定向，干扰结果）
• 如果提示 command not found: ab，先去软件商店装「Apache Bench」，安装完路径通常是 /www/server/apache/bin/ab，建议软链到 /usr/bin/ab 方便调用
• 避免用 -k（Keep-Alive）测试动态接口——PHP-FPM 默认不复用进程，长连接反而掩盖真实瓶颈；只有测静态资源或 Nginx 缓存命中率时才开

并发数设多少才算真实？看 PHP-FPM 和系统 fd 限制谁先卡住

你填 ab -c 500，不代表服务器真能扛住 500 并发。真实瓶颈往往不在代码，而在 PHP 进程池和 Linux 文件描述符（fd）上限——每个 TCP 连接、每个打开的文件、每个 fastcgi socket 都占一个 fd。

• 查当前 PHP 最大子进程数：ps aux | grep php-fpm | grep -v grep | wc -l，再对比 /www/server/php/80/etc/php-fpm.conf 里的 pm.max_children，如果前者长期接近后者，说明 PHP 已饱和
• 查系统级 fd 限制：cat /proc/sys/fs/file-max 和 ulimit -n（后者是当前用户限制），宝塔默认只设到 65535，高并发下必须调高，否则 accept(): Unable to allocate memory for new connection 这类错误会高频出现
• 改法不是只改 ulimit -n 65535 临时命令，得写进 /etc/security/limits.conf：加两行 * soft nofile 65535 和 * hard nofile 65535，然后重启 php-fpm 和 nginx

压测时 Nginx 报 502？大概率是 fastcgi_read_timeout 或 PHP 执行超时

不是 PHP 挂了，而是 Nginx 等不及——它默认只等 60 秒就断开，但压测中慢查询、锁表、Redis 阻塞都可能让单个请求卡住更久，导致大量 502，误判为服务崩溃。

• 检查站点配置文件里 location ~ \.php(.*)$ 块中是否有 fastcgi_read_timeout 300（单位秒），没加就手动补上；同时确认 fastcgi_connect_timeout 和 fastcgi_send_timeout 也设为一致值
• PHP 层也要同步放宽：/www/server/php/80/etc/php.ini 中 max_execution_time = 300，否则 Nginx 还没断，PHP 自己先 kill 掉进程
• 特别注意：如果用了宝塔的「防CC攻击」功能，它会按 IP 限速，压测时所有请求来自同一出口 IP，极易被误杀——临时关闭它再测

别只盯着响应时间，ab 输出里这三个字段才是关键

ab 结果里最常被忽略的是 Failed requests、Write errors 和 Time per request (mean, across all concurrent requests)。前两者暴露连接层问题，最后一个才是真正用户感知的延迟。

• Failed requests > 0？优先查 Nginx error log：tail -f /www/wwwlogs/your-site.error.log，常见是 upstream timeout 或 connection refused
• Write errors > 0？基本是客户端（ab）发包失败，说明本机网络栈或端口耗尽，执行 netstat -an | grep TIME_WAIT | wc -l，超过 3 万就得调 net.ipv4.ip_local_port_range
• Time per request 数值翻倍上涨？说明系统开始排队，不是 CPU 不够，而是 I/O 或锁竞争——此时看 iostat -x 1 和 mysqladmin processlist，比看 top 更准

压测不是比谁数字大，而是找出第一个开始抖动的阈值。这个值往往比理论峰值低 30%，但它才是你该守住的线。