TG咨询很多团队做服务器性能压测时，先设定一个并发数，再观察系统是否报错。这种方式容易得到“测试通过、线上变慢”的结论，因为真实流量通常包含访问间隔、请求类型、登录状态、缓存命中率和第三方依赖等差异。服务器性能压测的重点，不是把数字推到最大，而是还原系统将要面对的流量结构。
先把真实流量拆成可执行模型
开始服务器性能压测前，先从访问日志、接口网关记录或业务统计中提取请求比例。可以区分页面访问、搜索、提交、文件上传、登录和后台任务等类型，再记录每类请求的大致响应时间与调用链。
- 选取具有代表性的时间段，通常覆盖一个平稳时段和一个业务高峰；不要只截取异常分钟。
- 按请求占比建立场景，例如读取类请求占多数时，不能用全部写入请求替代。
- 准备脱敏测试数据，避免直接使用真实用户信息、支付信息或生产密钥。
- 使用 k6、Apache JMeter 或 Locust 等工具逐步发压，并让压测机本身具备足够网络和处理能力。
- 同时记录 p95、p99 延迟、错误率、超时数、数据库连接等待和队列积压，不能只看平均响应时间。
五个不能省略的压测场景
1. 稳态流量：确认系统能否长期工作
稳态场景模拟正常营业期间持续到来的请求。流量不必很高，但应保持一段足以暴露连接泄漏、缓存失效或队列缓慢增长的问题。对于普通网站，可先用接近预期高峰的负载运行约30至60分钟；后台处理较多的系统，则应根据任务周期延长观察时间。
重点看延迟是否逐渐上升、错误率是否随时间累积，以及数据库连接池、线程池和消息队列是否出现持续等待。若开始几分钟表现正常，后面才出现超时，问题往往不在瞬时承载能力，而在资源释放或任务堆积。
2. 突发流量：检验瞬时涌入后的恢复能力
真实访问可能来自新闻曝光、活动开场、通知推送或集中登录。突发测试不是简单地把并发数调高，而是在较短时间内将请求量从低位提升到高位，再观察系统能否稳定返回。
可采用“低负载—快速升压—保持—快速降压”的顺序。升压时间可以设置为几十秒到数分钟，具体取决于业务通知的到达速度。除了峰值期间的响应时间，还要检查降压后是否仍有积压任务、连接未释放或缓存击穿。服务器性能压测如果只记录峰值，不记录恢复阶段，就无法判断系统是否真正抗住了突发。
3. 阶梯加压：找出容量拐点而非追求极限数字
阶梯加压适合确定系统的安全运行区间。先从较低请求速率开始，每个台阶保持约5至15分钟，再逐步增加。每次增加后，等待延迟和错误率趋于稳定，避免把前一个台阶留下的排队请求误算到当前结果。
当 p95 或 p99 延迟出现明显跳升、超时比例持续增加，或数据库锁等待迅速扩大时，可以把该阶段视为容量拐点。容量拐点不等于服务器立刻宕机，通常应在拐点之前预留余量。不同接口的拐点也可能不同，搜索、上传和结算接口不能用同一个结论覆盖。
4. 混合业务：别用单一接口代表全站
真实流量往往同时包含读取、写入、鉴权和异步任务。只压一个“查询列表”接口，可能因缓存命中而表现良好，却掩盖写入接口对数据库锁、事务和磁盘提交的影响。
建立混合业务时，应按实际比例组合请求，并分别标记每类接口的响应时间。例如读取请求可以占较高比例，登录和写入请求保持较低比例，但具体配比必须以目标系统的日志为依据。测试结果要按接口拆分，既看整体错误率，也看关键写入操作是否因读取流量增加而变慢。
5. 依赖异常：验证降级和超时边界
服务器性能压测还应覆盖依赖服务变慢的情况，例如短信、地图、对象存储、支付网关或内部用户中心响应延迟。可在测试环境使用受控延迟、限制返回或模拟错误，不能对无授权的外部生产服务施压。
观察应用是否设置了合理的连接超时、读取超时、重试次数和熔断条件。若一个第三方请求变慢会占满全部工作线程，系统即使自身资源充足，也可能出现整体不可用。合格的方案应能快速失败、返回明确提示，或切换到缓存与异步处理，而不是无限等待。
执行后如何判断结果有用
服务器性能压测结束后，先核对流量回放比例与原始模型是否一致，再对比不同场景下的 p95、p99、错误率和恢复时间。报告中应写清测试环境、应用版本、数据规模、压测工具参数、持续时间及已知差异。
如果测试环境与线上架构不同，不要直接宣称线上可承载某个固定流量。更稳妥的做法是保留场景之间的相对变化，并在接近生产配置的环境中复测。每次改动连接池、缓存策略、数据库索引或限流规则后，也应重新执行受影响的场景。
常见问题
服务器性能压测一定要压到宕机吗？
不需要。多数业务更应先找到延迟和错误率开始恶化的拐点，再评估安全余量。破坏性测试应单独审批，并与正常容量验证分开。
并发数和请求速率有什么区别？
并发数表示同时处于处理状态的请求数量，请求速率表示单位时间进入的请求数量。接口响应时间变化时，同样的请求速率可能产生不同并发，因此两者不能互相替代。
压测数据应该使用真实数据吗？
通常不应直接使用生产个人信息。可以保留数据量级、字段长度和冷热分布等特征，使用脱敏或专门构造的数据进行测试。
什么时候需要重新做服务器性能压测？
架构、数据库版本、缓存策略、关键接口逻辑、部署规格或流量结构发生变化时，都应至少复测受影响场景。服务器性能压测的价值在于持续校验，而不是只在上线前完成一次。
