为什么先压测，再谈优化

很多站点出现卡顿、502、504 时，第一反应是“加内存、升 CPU”。但并发能力不足的原因可能出在网络带宽、Web 服务器连接数、PHP 进程数量、数据库查询，甚至磁盘 I/O。在不清楚瓶颈位置的情况下盲目升级配置，往往投入了成本却看不到效果。压力测试的作用，就是用可控的请求量把“感觉慢”变成可复现、可量化的现象，再顺着监控数据找到真正的短板。

压测前的准备工作

• 备份与回滚：改动 Nginx、PHP、MySQL 配置前，先备份原配置文件与数据库，确认能快速还原。
• 选择压测时间：尽量避开业务高峰，或直接在测试环境、预发布环境进行。
• 明确测试对象：先压静态页，再压无数据库查询的动态页，最后压完整业务接口，逐层排除干扰。
• 准备监控：压力测试的同时必须观察服务器指标，否则只拿到“失败率”却不知道原因。

常用压测工具与基本思路

工具选择取决于测试目标：

• ab：安装简单，适合快速验证单个 URL 的吞吐表现，属于单线程模型，压测机自身容易先成为瓶颈。
• wrk：支持多线程与长连接，更能压出 Web 层的真实能力。
• JMeter / k6 / Locust：支持脚本化、参数化、并发梯度，适合模拟登录态和完整业务链路。

无论使用哪种工具，建议遵循由低到高、阶梯加压的原则：从很小的并发开始，观察响应时间与错误率的变化拐点。响应时间开始明显上升、错误开始出现的那个区间，通常就是瓶颈的入口。

压测过程中需要重点观察的指标

系统层

• CPU：是用户态吃满、系统态吃满，还是 iowait 偏高。
• 内存：可用内存是否持续下降，是否触发 swap。
• 磁盘：读写等待、IOPS 是否饱和。
• 网络：带宽是否跑满，连接数是否异常堆积。

Web 与运行环境层

• Nginx：访问日志中的响应时间、499/502/504 状态码占比。
• PHP-FPM：进程池是否被打满，是否出现“pool seems busy”类提示。
• 数据库：当前连接数、慢查询数量、锁等待情况。

在宝塔面板中，可以通过系统监控、网站日志（默认位于 /www/wwwlogs/ 目录，以实际安装路径为准）、PHP-FPM 慢日志和 MySQL 慢查询日志配合排查。PHP-FPM 慢日志需在配置中开启请求超时阈值，MySQL 慢查询日志可在数据库设置中开启。

分层定位：从外到内找出真正的瓶颈

1. 网络与带宽层：如果带宽已跑满，而 CPU、内存都很空闲，说明瓶颈在出口带宽或 CDN 回源策略，而不是服务器配置。
2. Web 层：静态资源响应慢、连接被拒绝，通常是 Nginx 工作进程数、单进程连接数或 keepalive 设置偏保守。
3. 应用层：动态请求排队、响应时间随并发线性上升，多为 PHP-FPM 可用进程不足，或代码中存在阻塞型外部调用。
4. 数据库层：CPU 不高但响应慢，常见于缺少索引、慢查询、连接数不足或锁竞争。
5. 存储层：iowait 持续偏高、日志写入量大，说明磁盘性能或日志策略需要调整。

针对瓶颈的配置优化方向

Nginx

• 根据 CPU 核心数合理设置工作进程数，并同步调整单进程最大连接数。
• 开启并合理配置 keepalive，减少频繁建连开销；对静态资源启用浏览器缓存与压缩。
• 为动态请求设置合理的超时时间，避免请求长时间挂起占用连接。

PHP-FPM

• 进程管理方式建议使用动态或静态模式，并按“可用内存 ÷ 单进程实测常驻内存”来估算进程上限，预留系统与数据库所需内存。
• 开启慢日志，定位执行时间过长的脚本，再回到代码层面优化。
• 确认 PHP 版本与扩展是否满足业务需求，避免加载无用扩展增加内存开销。

MySQL

• 打开慢查询日志，优先处理高频且执行时间长的语句，补足必要索引。
• 根据实际连接需求调整最大连接数，连接数并非越大越好，过多连接会加剧上下文切换。
• 关注临时表、排序、锁等待等指标，判断是查询问题还是结构问题。

缓存与架构

• 对变化不频繁的数据使用内存缓存或页面缓存，直接削减数据库压力。
• 静态资源与图片走对象存储或 CDN，把带宽压力从源站转移出去。
• 当单机优化到瓶颈后，再考虑读写分离、负载均衡等横向扩展方案。

优化后必须回归验证

每次只调整一类配置，然后用与之前一致的压测脚本、一致的并发梯度重新测试，对比响应时间、错误率和资源占用的变化。只有数据可复现，优化才算真正完成。切忌一次性修改多项参数，否则无法判断哪项改动起了作用。

常见误区

• 只看失败率不看资源：错误的定位会让优化方向南辕北辙。
• 把并发数等同于在线用户数：两者不是同一概念，压测并发是瞬时请求压力。
• 压测机成为瓶颈：压测机的带宽、端口和 CPU 限制会掩盖服务端的真实表现。
• 压测生产环境：可能影响真实用户，应优先在测试环境进行。

压力测试不是一次性动作，而是配置调整的度量工具。先用数据找到瓶颈，再针对瓶颈调整服务器与软件配置，最后用同样的方法验证效果——这套闭环，比盲目升级配置更能提升站点的并发承载能力。