做性能测试这些年我面试过不少候选人也带过不少刚入行的同学。大家最常问的一个问题就是“性能测试到底测哪些指标”说实话这个问题本身没有标准答案因为不同系统、不同业务场景下你关心的指标完全是两回事。但反过来说如果连最常见的几类指标都说不清那后面的压测脚本设计、结果分析、瓶颈定位就都没法谈。这篇文章我就把性能测试里最常用、也最容易被误读的几组指标一次性讲透包括它们到底是什么、怎么算、怎么设阈值、怎么组合起来判断系统当前的状态以及我自己在实战中踩过的一些坑。适合刚接触性能测试的测试工程师也适合写了几年脚本但分析结果总感觉不够深入的同学参考——如果你正在准备性能测试面试题这篇文章里的内容也基本把高频考点覆盖了。1. 指标不是越多越好——先搞清楚性能测试到底在看什么性能测试看起来是在“找数字”实际上是在回答三个问题系统能不能扛住预期流量、系统在多快的时间内响应、系统在压力下的稳定性如何。围绕这三个问题所有指标其实可以分成两大类一类是业务/用户视角指标比如响应时间、错误率、吞吐量这些是外部能感知到的另一类是资源/系统视角指标比如CPU、内存、磁盘IO、网络带宽、GC频率这些是内部运行状态的反映。刚入行的时候我有个习惯觉得指标收集得越全越安全于是在压测时把能开的监控全开一遍最后生成一份几百行的报告。但真正分析的时候才发现大部分数据根本用不上甚至指标之间互相矛盾反而把人绕晕了。后来我慢慢总结出一个原则先确定问题再挑选指标。你是想验证系统能不能支撑双十一峰值那就重点看TPS、响应时间P99、错误率、CPU和内存。你是想定位一次接口超时率突增的根因那就要把GC日志、慢查询日志、网络重传率这些偏底层的指标纳入视野。还有一个容易忽略的分层问题。性能指标不能只看“一层”。举个例子一个请求从客户端发起到网关再到应用服务最后落到数据库每一层的耗时和吞吐都不一样。如果只看网关层的平均响应时间是1秒就判定系统没问题那很可能掩盖了应用层已经出现大量线程阻塞的事实。所以我做压测分析时有个习惯把链路里每一层的核心指标都记录一份哪怕当前用不上也要为后续排查留底。下表是我在通用压测场景下默认采集的指标集合几乎每个项目都适用指标类别具体指标观测目的吞吐类TPS、QPS、吞吐量字节/秒判断系统处理能力是否达标响应类平均响应时间、P95、P99、最大响应时间判断用户体验和系统稳定性质量类错误率、超时率、重试率判断系统是否在正常处理请求资源类CPU使用率、内存使用率、磁盘IO、网络带宽、GC耗时定位瓶颈发生在哪一层连接类活跃连接数、线程池活跃线程数、数据库连接池使用率判断是否存在资源争抢或耗尽这个表格不是让你死板照抄而是提供一个框架。不同项目要按需增删——比如接口是纯内存计算磁盘IO就可以不采比如压测对象是文件上传服务那网络带宽和磁盘写入就是核心指标。在面试中如果被问到“性能测试有哪些指标”我建议不要只背名词而是按“用户视角–系统视角–业务视角”三层来答。用户视角是响应时间、错误率、TPS系统视角是CPU、内存、磁盘、网络业务视角是转化率、订单量、支付成功率这些由性能波动引发的业务结果变化。能把这个层次说清楚比背出二十个名词要加分得多。2. 响应时间的平均值陷阱P95、P99为什么比平均值更重要响应时间是性能测试里最直观的指标但也是被用错最多的指标。大多数人刚开始看报告第一眼就是平均值。平均值确实简单但它会掩盖长尾问题。我举个例子你就明白了。假设一次压测一共发起了100个请求其中90个请求响应时间是200毫秒10个请求响应时间是2秒。算下来平均响应时间是380毫秒——看起来非常健康。但如果你再问一句有百分之多少的用户体验是超过1秒的答案是10%。这10%的用户很可能已经不耐烦了甚至已经流失了。如果这个接口是支付接口那10%的失败率可能是完全不可接受的。所以业内更看重分位数值也就是把所有的响应时间从小到大排序取第95个百分位P95、第99个百分位P99。P95的意思是“95%的请求响应时间都小于这个值”它代表的是大多数用户的真实体验P99则更进一步代表最差的那1%用户的情况。我在压测中通常会同时记录P50中位数、P75、P95、P99构造一条“响应时间分布曲线”来看系统是否存在长尾。如果P50和P95差距很小说明响应时间分布集中系统运行稳定如果P50很低但P99异常高那说明绝大多数请求很快但少数请求遭遇了极端情况——这通常指向GC停顿、线程池排队、锁竞争等定时或偶发问题。关于响应时间的“健康标准”不要照搬任何人的死数字。不同类型的业务可接受的范围天差地别业务类型典型可接受响应时间重点关注分位静态资源、CDN50~200msP50、P95普通Web接口500ms~2sP95、P99支付、下单等核心链路P99 500msP99、最大响应时间批处理、离线任务分钟级~小时级整体耗时、吞吐量表格里的数值是我个人经验不是行业标准重点在于说明**在设指标基线之前先把业务对响应时间的容忍度搞清楚。**一个给内部运营看的数据报表接口P99跑到3秒完全没问题但一个用户点击下单的接口P99超过1秒可能就需要紧急优化了。还有一个现象值得警惕——响应时间拐点。当你逐渐增加并发数时前期响应时间可能平稳甚至略微下降但随着并发继续升高响应时间会突然飙高形成一个明显的拐点。这个拐点对应的并发数就是系统的“软容量上限”。我压测一个订单系统的经验是并发从50涨到200时P95从400ms缓慢涨到700ms但当并发到250时P95直接跳到2.8秒。这就是典型的线程池排队打爆了。找到这个拐点比拿到任何单个数字都有意义因为它直接告诉你线上跑到什么流量就该扩容了。3. TPS、QPS与吞吐量三个容易混淆又决定系统容量的数字面试里特别喜欢问TPS和QPS的区别因为不少人是真的搞混。QPS全称是Queries Per Second每秒查询数通常指一个接口每秒能处理的请求次数。TPS全称是Transactions Per Second每秒事务数指的是每秒能完成的完整业务事务数量。两者的最关键差异在于一个事务可能包含多次请求。举个例子一个完整的“下单”事务可能先调用查询库存接口再调用创建订单接口最后调用扣减库存接口。假如一次下单逻辑要发3个请求系统每秒处理了300个请求QPS300但实际上每秒只完成了100个下单操作TPS100。所以在压测时你的TPS不达预期未必是系统处理能力不够也可能是因为事务脚本里单个事务包含的请求数太多了。吞吐量在性能测试里经常跟TPS混用严谨一点的话吞吐量指系统单位时间内处理的数据量单位可以是字节/秒、请求数/秒或事务数/秒。你看到报告里的“Throughput”通常指的是每秒完成的请求数或事务数看具体工具定义。如果关心的是数据传输能力那还要看“Received KB/sec”和“Sent KB/sec”这两个单位才是字节层面。还有一条黄金公式做容量预估的时候几乎天天用并发数 吞吐量 × 平均响应时间。这是排队论里的Littles Law在Web系统里的应用。我来算给你看。假设你的线上目标是要支撑1000 QPS而这个接口的平均响应时间是0.2秒那么系统内同时处理的请求数等价并发数需要保持在1000 × 0.2 200。也就是说你的应用服务器至少要让200个请求同时在处理中才能支撑1000 QPS的目标。如果线程池只有100个线程那就算机器配置再高QPS也大概率卡在100 / 0.2 500左右上不去。这个公式还可以反向用先记录当前并发数和平均响应时间两者相除就是当前吞吐量。如果压测时响应时间不断上涨、吞吐量却停滞不动说明系统已经进入了资源耗尽后的“假死状态”这时候加压已经没有意义应该先调优。关于吞吐量还有两个常见误区。第一最大吞吐量不是靠无限加压测出来的而是通过阶梯加压找出来的。我常用的方法是以50并发起步每次增加25或50每档运行3~5分钟观察吞吐量变化。当吞吐量不再随并发增加而明显增长甚至开始回落那个点就是系统的最大吞吐能力。第二不要只看相对值要看趋势。有的同学测出来吞吐量是2000 QPS就觉得很满意但没有看测试时长——如果只稳定跑了1分钟那这个数字参考价值很低如果持续跑了3个小时仍然稳定在2000 QPS这个数字才真的可信。4. 资源利用率CPU、内存、磁盘、网络的健康线到底划在哪系统资源指标是定位瓶颈的关键但也是最容易被“看走眼”的部分。很多人拿到监控图发现CPU到达90%就开始慌其实CPU高不一定是坏事——如果系统在正八经地算业务CPU打满说明书处理能力强如果CPU很高但TPS上不去那才说明在无效空转。反过来CPU和内存都很低TPS也趴在地上那系统大概率卡在IO等待或锁等待上加配置是解决不了问题的。我先说CPU。看CPU不能只看整体使用率还要拆成user态、system态和iowait。user态高说明在做计算system态高说明在内核调用和上下文切换上花了太多时间iowait高说明CPU在等磁盘或网络数据属于IO瓶颈。我给出一个经验参考值持续超过80%的CPU使用率需要关注超过90%且伴随TPS停滞就要重点排查。但service mesh、Sidecar这类额外组件会让CPU的消耗比预期高很多这也是排查时要考虑到的因素。内存要看的东西更细。除了物理内存占用率还要关注swap用量、JVM堆内存的变化趋势和GC频率。压测一个Java服务时如果内存曲线呈锯齿状上涨且每次下降都是因为Full GC那这就是典型的堆设置不当或者内存泄漏前兆。我不能一概而论说GC多少次就一定有问题但以下原则可以参考压测稳定阶段Young GC频率应该相对规律Full GC应该极少发生或完全不发生如果Full GC频繁出现响应时间必然有刺P99会被拉高。磁盘方面重点看IO等待时长await、IO使用率util、IO队列长度。不要被util100%吓住SSD和机械硬盘对util100%的含义完全不同。更实用的做法是看await是否持续偏高比如超过20ms以及IO队列是否持续大于2这代表IO子系统已经跟不上请求速度后面的请求在排队。网络方面除了带宽使用率还要看TCP重传率、连接建立失败率和TIME_WAIT连接数量。我曾经压测一个高并发短连接场景服务器CPU、内存都正常但吞吐量就是上不去一查发现TIME_WAIT连接堆积了十几万直接把端口资源耗尽了。这种问题看单个资源指标根本发现不了必须把网络连接状态纳入监控视野。还有一点特别重要资源指标按实例拆分看不要只看集群总和。比如你有3台应用服务器每台CPU都是30%总和看起来是90%感觉很紧张但实际上每台都远没打满这个集群还有很大的余量。反过来3台机器的CPU分别是80%、10%、10%平均值看着只有33%但第一台机器已经命悬一线了流量稍微一波动它就会成为瓶颈。做负载均衡调优的时候看单机曲线比看平均值有用得多。5. 从单点指标到瓶颈定位学会让数字之间相互印证单看任何一个指标都无法得出结论性能分析本质上是多个指标交叉印证的过程。这就好比医生看病不会只看体温这一个指标而是要把体温、血常规、影像学检查结果结合起来才能诊断。我把常见的指标组合和它们指向的问题整理成下面这张表实战中非常有用指标特征组合大概率问题方向CPU高 响应时间上升 TPS不再增长计算密集应用代码逻辑或GC消耗CPUCPU低 内存高 频繁Full GCJVM堆内存不足或内存泄漏CPU低 磁盘util高 await高磁盘IO瓶颈慢查询或日志刷盘太频繁CPU低 网络重传率高 响应时间抖动网络链路不稳定或出口带宽受限线程池活跃线程打满 队列积压 响应时间暴增线程池配置过小或上游依赖响应缓慢数据库连接池耗尽 应用服务日志报连接超时SQL慢查询或连接池配置不当响应时间P95上升 单条请求耗时分布出现尖刺代码中偶发的锁竞争、Full GC、网络抖动说一个真实的案例。我之前压测过一个报表查询接口现象是TPS从800降到300同时P95从1秒飙到6秒CPU使用率却只有40%内存也不高。第一反应是数据库问题但慢查询日志里并没有明显恶化的SQL。后来把排查范围扩大到GC日志才看到Full GC每隔十几秒就发生一次每次停顿都要1秒以上直接把线程全部冻住了。根源是报表查询会一次性加载大量对象堆内存根本吃不住。调整了查询逻辑、改成流式读取之后Full GC消失TPS回到1000以上。这个案例想说明的是如果当时只看CPU和内存这个瓶颈可能就要排查很久。但把线程状态、GC日志、响应时间分布放在一起看很快就锁定了方向。所以我的分析习惯是第一步拿到压测结果后先看“大三角”——TPS、响应时间、错误率——判断系统整体是健康、恶化还是崩了第二步看资源指标找出跟“大三角”同步恶化的那一项第三步针对疑似瓶颈深入看专项指标比如GC日志、线程dump、慢SQL。这三步走完绝大多数瓶颈的定位不需要超过一小时。对了还有一点容易忽略压测机的资源状态。如果你用JMeter跑分布式压测压测机自身的CPU和网络出口带宽也会成为瓶颈导致服务端看到的流量上不去、但压测机已经“压不动了”。这种情况出来的指标完全不可信。所以我每次压测前都会先确认压测机资源充足并且尽量让压测机和服务端不要跑在同一台物理机上。6. 一次实战聚合报告里的数据到底应该怎么读很多人跑完JMeter习惯只看最后生成的聚合报告Aggregate Report表格瞄一眼Average和Error%就完事。这种做法在性能测试里相当危险。聚合报告提供的数据维度很多但如果不会读就拿不到真正的结论。我把JMeter聚合报告的每一列按实战含义拆开讲一下Samples请求总数。如果压测时长固定Samples越多说明吞吐越高。Average平均响应时间最容易迷惑人的一个数上一节已经详细说过。Min / Max最低和最高响应时间。最高值如果异常大往往伴随着一次GC或线程等待偶尔出现一次不用太紧张频繁出现就要查了。Std. Dev.标准差反映响应时间的离散程度。这个值越大说明系统越不稳定。Error%错误率。注意这里的“错误”可能是断言失败不一定是请求失败。如果断言条件设置得不合理比如要求响应里包含某个非固定字符串错误率可能会被虚假拉高。Throughput单位时间内完成的请求数通常就是QPS/吞吐。Received KB/sec / Sent KB/sec数据吞吐量主要看接收方向是否打到网络带宽上限。聚合报告的正确打开方式不是等压测跑完后一次性看而是分阶段看。我在压测时习惯把测试分成预热阶段、稳定阶段、加压阶段和恢复阶段。预热阶段前1~2分钟的数据不纳入统计稳定阶段中间10~30分钟才是考核系统的核心区间加压阶段用来观察拐点恢复阶段用来观察系统是否有资源回落、连接是否正常释放。另外聚合报告只能告诉我们“发生了什么”但解释不了“为什么发生”。所以我会同时保存压测期间的监控数据包括服务端的CPU、内存、GC、数据库连接池状态等。报告和数据的时间戳要能对齐才能做指标联动分析。为了这个目标我跑JMeter时一定会勾选“Save response data”或者至少保存原始CSV结果文件这些原始数据可以留到后面做二次分析比如单独统计某段时间的P99。再分享一个压测步骤的参考流程基本可以应用到大多数接口压测场景准备压测脚本明确一个“事务”包含哪些请求配置合理的断言单机小并发比如5~10并发跑通脚本确认功能正常、数据无污染记录系统本底指标包括空闲时的CPU和内存水平用阶梯加压方式从50并发开始每档增加50每档运行3~5分钟持续观测TPS、响应时间、错误率和资源指标的变化趋势找到吞吐量拐点若存在则把拐点前后各档的详细数据保存下来若需要稳定性评估则保持在拐点80%左右的压力持续运行1~3小时汇总各阶段数据输出最终结论和优化建议。这个流程看起来很简单但执行过程中每一步都有细节。比如第3步容易被跳掉——跳过之后你在压测时如果发现CPU已经60%了你根本不知道这个60%是不是本来就有其他后台任务在跑结论自然就打折扣。7. 工具选型与采集配置哪些坑会让你拿到一堆假数据最后聊一下压测工具和监控采集的选型与配置。工欲善其事必先利其器但工具选不好、配置不对跑出来的指标是假数据后面分析得再认真也是白费功夫。先说说JMeter。JMeter本身足够强大但要跑好需要做几件事线程组里合理设置Ramp-Up时间让并发逐步增加而不是瞬间打满——瞬间满负荷压测会直接触发系统保护机制拿到的是系统扔进来的“失败风暴”而不是真实容量配置聚合报告之外最好加一个Backend Listener把数据发送到InfluxDB再通过Grafana做实时监控面板。这样可以在压测过程中盯着指标曲线看变化而不是等压测结束才看纸面数据。如果项目对性能数据的准确性和实时性要求更高可以考虑下探到系统监控层。服务端用Prometheus Node Exporter采集CPU、内存、磁盘、网络应用层用Micrometer暴露指标数据库则关注连接数、慢查询数和缓冲池命中率。把这些数据全部落到同一个时间轴之后压测结果和系统状态就可以逐秒对应了。再讲几个我在工具配置里真实踩过的坑。第一个坑是断言配置不当。有一次压测一个返回纯JSON的接口我在断言里判断响应体包含特定字符串结果线上返回的数据顺序有变化断言大量失败错误率从0飙到40%。那次压测彻底作废。后来我意识到断言应该验证“业务有效性”而不是“响应格式的偶然细节”。对压测来讲常见做法是用状态码加一个必要的业务字段判断就够了。第二个坑是Think Time思考时间设为了0。真实用户不会毫秒不歇地发请求中间必然有浏览、输入、犹豫的时间。如果完全去掉Think Time压测出来的TPS会虚高到不真实同时系统也会因为极端流量而提早暴露崩溃点。对于容量评估类压测建议按业务习惯配置合理的Think Time对于容量极限摸底则可以去掉——但你心里得清楚这两类压测的目的本来就不一样。第三个坑是分布式压测时压测机规格不足。JMeter的Master节点只管调度真正发压的是Worker节点。如果Worker的CPU和内存不够线程调度就会跟不上吞吐量上不去不说响应时间也会被压测机自身拖累。我的经验是单台Worker跑200~500个线程就够了再多就要加Worker同时确保Worker到目标服务端的网络路径没有瓶颈。第四个坑是缺少“压前基线”的采集。前面提过多次压测前一定要记录系统空闲时的资源状况。比如系统上本来就跑着定期任务每5分钟刷一次CPU压测结果在高峰段出现规律的抖动如果不知道这个定时任务很可能会花大力气去查根本不存在的代码问题。工具的选型本身不复杂单接口快速验证可以用wrk或ab复杂业务链路压测首选JMeter服务网格环境或云原生场景则更推荐k6或Locust这类支持脚本化且易与CI/CD集成的方案。但无论哪个工具重点都在于你能否把采集到的数据对齐到同一个时间维度并且能解释为什么会呈现这样的曲线。工具只是管道指标才是水源。我现在做压测时有一个固定习惯每一轮压测跑完都会把原始CSV、聚合报告、监控截图和压测参数配置打包成带时间戳的文件夹存起来。几个月后如果线上再出问题翻出当时的压测记录来对比经常能迅速锁定变化点。性能测试的指标并不是压完就结束的一次性数字而是一个项目长期的体检档案。这套数据积累得越多你对系统真实容量的掌控感就越强后续扩容量级评估和容量规划也才真的有据可依。