TG咨询很多团队做服务器性能压测时，习惯把“最多能同时承载多少用户”作为主要结论。但峰值并发只是一个瞬间指标，无法说明请求是否及时完成，也不能反映数据库、消息队列或第三方接口变慢后的连锁影响。一个短时间冲到较高并发、随后大量超时的系统，并不能算性能良好。
更可靠的判断方式，是把并发规模、请求结构、响应延迟、错误率和持续时间放在同一张结果表中。只有这些条件同时满足业务目标，压测结论才有上线参考价值。
先把“并发量”还原成真实负载
并发用户不等于每秒请求数。用户停留时间、页面请求数量、接口调用顺序和思考时间，都会改变服务器收到的实际压力。例如一个预约页面可能先加载资源，再查询可用时段，最后提交订单；如果只压最后一个接口，得到的吞吐能力通常会高于完整流程。
至少准备三类流量模型
- 基准流量：模拟日常访问，用来观察正常资源消耗和基础延迟。
- 高峰流量：按照预期峰值逐步加压，检查系统在目标负载下是否达到服务指标。
- 突发流量：在较短时间内快速增加请求，观察线程、连接池和队列能否平稳吸收冲击。
模型中应写清请求比例、并发增长速度、用户等待时间、测试数据规模和接口顺序。比如读取接口占多数时，测试流量就不能用同等数量的写入请求替代；否则数据库锁、日志写入和事务提交带来的压力会被夸大或遗漏。
峰值之外，更应观察四组指标
吞吐量与延迟要同时看
吞吐量反映单位时间完成了多少请求，延迟反映单个请求等待了多久。系统可能在CPU接近饱和时仍保持较高吞吐量，但尾部请求已经明显变慢。建议同时记录平均延迟、P95和P99延迟，并按接口或业务步骤拆分，而不要只看全站平均值。
例如，普通内容读取可能允许大多数请求在约1至3秒内完成，而身份验证、库存锁定或订单提交通常需要单独设定更严格的超时和错误率目标。具体阈值应由业务确认，不能直接套用某个通用数字。
错误率要区分类型
HTTP 5xx、连接失败、客户端超时、业务拒绝和校验失败的含义不同。测试报告应分别统计，并保留状态码、异常信息及发生时间。若压测工具显示成功率很高，却把大量业务失败响应当作“请求完成”，结论仍然会失真。
稳定性要覆盖持续运行
短测只能发现瞬时瓶颈，难以暴露连接泄漏、缓存失效、日志膨胀或队列积压。服务器性能压测通常应包含预热阶段、目标负载阶段和降载观察阶段。持续时间可从几十分钟起步，重要系统则应根据资源变化速度延长到数小时；时间长短要结合内存增长、连接回收周期和业务批处理周期确定。
一套更容易复现的执行流程
- 固定环境：记录服务器规格、操作系统、容器限制、网络带宽、数据库版本和测试数据量，避免环境差异掩盖结果。
- 准备数据：使用接近真实分布的账号、商品、订单或内容数据，避免所有请求命中同一条记录，造成不真实的缓存效果。
- 编排场景：用 JMeter 或 Locust 编写登录、浏览、查询、修改等完整流程，并为每个步骤设置权重、等待时间和断言。
- 分阶段加压：从低负载开始，按固定梯度提升并发；每个档位保持足够时间，等延迟和资源曲线稳定后再进入下一档。
- 同步采集资源：记录处理器使用率、内存、磁盘等待、网络流量、线程数、连接池、数据库锁和队列长度。Prometheus 可用于统一保存时序指标，但采集本身也要避免给被测环境增加明显负担。
- 重复关键档位：至少重复目标负载和临界负载，比较延迟、错误率和资源曲线是否接近。差异很大时，应先排查缓存、后台任务、网络抖动或测试数据问题。
怎样判断结果是否值得信任
不要只问“最高并发是多少”，而要问“在什么条件下，系统能稳定完成什么工作”。报告至少应包含负载模型、持续时间、成功请求定义、P95和P99延迟、分类型错误率、资源峰值、瓶颈位置以及恢复表现。
如果延迟随并发平滑增加，降载后资源能够恢复，且错误率始终处于业务允许范围，通常说明系统还有可预测的容量边界。若并发只增加一点，P99突然抬升、连接池耗尽或队列持续增长，则应把该档位视为风险拐点，而不是继续追求更高峰值。
定位问题时应一次只改变一个主要变量，例如只调整应用线程数、只更换数据库索引或只扩大网络带宽，并重新执行同一场景。这样才能确认改动是否真正改善了瓶颈，而不是让多个变化互相掩盖。
结语：用可用容量替代漂亮峰值
服务器性能压测最终要回答的是系统能否在真实业务条件下稳定运行，而不是测试工具能把并发数字推到多高。把流量结构、尾部延迟、错误类型、持续时间和恢复能力纳入判断，才能得到可用于容量规划和发布决策的结果。
常见问题
峰值并发越高，服务器性能越好吗？
不一定。若高并发伴随大量超时、业务失败或不可恢复的资源积压，这个峰值没有实际使用价值。
压测必须使用生产数据吗？
不应直接使用包含真实个人信息的生产数据。可以脱敏后复制数据分布和规模，重点保持访问热点、记录数量与关联关系接近真实情况。
为什么平均响应时间正常，用户仍觉得很慢？
平均值可能掩盖少数极慢请求。应重点检查P95、P99以及关键流程中最慢的步骤。
压测结束后还要继续观察吗？
需要。降载后的资源回落、连接释放、队列清空和错误恢复情况，能帮助判断系统是否存在泄漏或积压。
