做性能测试这么多年经常遇到第一次接触压测的同事跑完一轮就兴奋地拿着JMeter聚合报告里的Average和Throughput来汇报“响应时间200msTPS 300稳了”结果上线第二天就被真实流量打出一身冷汗。其实响应时间平均值、吞吐量这些只是最表面的几个数字如果不懂它们之间的关系不知道哪些指标才是压测的关键测试报告就只能是一堆自欺欺人的数字游戏。这里我打算把性能测试中常见的指标从头到尾捋一遍说清楚每个指标到底测什么、怎么读、怎么和场景关联。无论你是刚开始做压测的测试工程师还是需要分析线上容量问题的后端开发看完这篇至少不会再把TP90和平均响应时间搞混也不会在看到CPU没打满时就盲目说系统有瓶颈。1. 先理清性能测试到底在测什么1.1 性能指标的本质性能测试不是“用工具压一下接口看返回快不快”这么简单。它的本质是做一次受控的实验给系统施加一个明确的负载然后观察系统在这个负载下表现出的数字。这些数字就是性能指标。指标的意义在于把“快”和“慢”、“好”和“坏”从抽象感受变成可以量化的数据。正因为性能指标需要支撑后面的容量评估、故障定位、代码调优所以它必须可测量、可重复、可对比。如果一次压测跑出来的响应时间是200ms另一次同样的压力跑出来是2s那这两组数字背后一定有变量发生了变化可能是环境变了、代码变了、数据量变了也可能是测试方法本身有问题。这才是性能测试真正要回答的问题在什么条件下系统的能力边界在哪里。从用户视角和系统视角两个维度看指标可以分成两大类。用户能感知到的是外部指标响应时间、吞吐量、错误率。系统内部运行状况是内部指标CPU使用率、内存占用、磁盘IO、线程池状态、GC停顿时间。外部指标告诉你“系统行不行”内部指标告诉你“为什么行或者为什么不行”。我见过不少性能测试报告只写了外部指标资源和后端状态完全是黑的这种报告拿去排查问题时几乎没有任何指导价值。1.2 指标之间的关联关系常有人说性能指标太多了记不住。我建议你不要死记指标名称先把它们之间的关系理顺。可以拿一条城市道路来做类比。并发用户数是路上的车流量单位时间通过路口的车辆数就是吞吐量TPS每辆车从路口一头开到另一头的耗时就是响应时间车辆之间发生碰撞或者抛锚的比例就是错误率。车少的时候车都能顺畅通过每辆车耗时短但总通过量不高。随着车流增加单位时间通过路口的车变多车辆通行速度开始变慢。到了路口的饱和承载量再多车也过不去了通过的车辆数到达峰值。如果继续强行往路口塞车排队越来越长通行时间急剧增加碰撞和事故也开始变多。这个类比基本就是系统性能曲线的缩影。压测过程中我们会看到响应时间随着并发升高而变大TPS先线性增长然后增速放缓最后持平甚至掉头向下错误率则在拐点附近开始冒头。理解了这条曲线的形状很多指标不再孤立。它就是同一个负载变化下系统外部表现的一组连锁反应。1.3 如何设定可度量的测试目标性能测试必须在开始之前定义“什么是达标”。没有目标的压测最后拿到一堆数字也不知道该不该高兴。目标通常以SLA服务等级协议的形式写下来例如某个订单查询接口负载条件响应时间要求吞吐量要求错误率要求200并发持续压测15分钟TP95 ≤ 500msTPS ≥ 300≤ 0.1%这个SLA包含三层信息负载大小200并发、持续时间15分钟、量化阈值响应时间、吞吐量、错误率。缺了任何一项后续都无法评判结果。目标也不是拍脑袋定的通常来自两类依据一类是业务预期比如产品经理要求高峰期所有列表页在1秒内展示另一类是现有系统的基线表现比如线上平稳状态下平均响应时间300ms那压测目标可以定在TP95≤500ms留出余量。2. 功能维度响应时间、吞吐量、错误率别只看平均值2.1 响应时间平均值会骗人百分位才是真相响应时间是最直接的用户感知指标定义是从客户端发出请求到收到完整响应所花费的时间。听起来简单但在统计响应时间时很多人会掉进平均值陷阱。举个例子一个接口跑了100个请求99个请求耗时100ms只有1个请求耗时10s平均响应时间是(99×0.110)/100≈199ms。从平均值看系统响应很快但实际体验是那1个请求的用户已经等到抓狂。平均响应时间被极少数慢请求拉高或者拉低掩盖了真实的质量情况。正确做法是看百分位响应时间也就是TP50、TP90、TP95、TP99这些指标。它们的含义是把所有请求的响应时间从小到大排序TP95就意味着有95%的请求响应时间小于等于这个值。比如TP95500ms代表绝大多数用户都能在500ms内得到响应。压测报告里应优先看TP90和TP99这两个数字对长尾问题非常敏感。我曾经排查过一个在线支付回调接口平均响应时间一直稳定在250ms左右但线上经常有人反馈支付结果通知很慢。后来在压测时单独看了TP99发现达到了2.8秒。顺着TP99去翻日志定位到偶发的数据库连接池等待和一次Full GC停顿。如果只看平均值这类问题会一直藏在水下。所以实测中我建议在聚合报告里同时记录Avg、TP90、TP95、TP99而且判断达标与否以TP95或TP99为准平均值只作为参考。2.2 TPS与QPS单位时间内到底能处理多少请求吞吐量代表系统单位时间内能够处理的请求数量常见单位是Requests/sec。后来在业务侧又出现了TPS和QPS这两个词。TPS是事务每秒QPS是每秒查询数。很多人在混用它们但其实需要区分业务语义。对于简单HTTP接口一次请求通常等于一个事务此时TPS和QPS数值上可以看成等价。但对于复杂业务则不成立。典型如下单业务客户端一次点击“提交订单”后端可能同时调用用户校验接口、库存扣减接口、订单写入接口、消息推送接口。如果以整个“下单”为事务一次成功下单产生了几次内部HTTP查询那么TPS统计的是下单次数QPS统计的是所有内部接口被调用的次数。两者数值可能相差3到5倍。所以写测试目标时一定要先约定清楚本次测的是“用户事务”还是“后端查询请求”。JMeter聚合报告里有个Throughput字段单位是requests per second。它统计的是所有Sampler的请求数不是业务事务数。如果你的脚本里一个业务环节包含了3个HTTP请求JMeter的Throughput会比真实的业务TPS高3倍。这就是为什么不能直接把JMeter里的Throughput当成业务TPS写进报告。需要在脚本层面设计好业务逻辑或者二次计算一个问题场景对应一个Sampler或者一个Transaction Controller。2.3 错误率比响应时间更先暴露问题错误率等于失败请求数除以总请求数。但要搞清楚什么叫“失败”。HTTP层面来说4xx和5xx都意味着请求异常但业务上可能4xx是正常的参数校验不通过5xx才是系统故障。JMeter默认只统计连接失败、超时这类IO错误HTTP状态码只要不是网络异常它都会当作成功。如果不在脚本里配置响应断言很可能5xx响应都被记成成功错误率保持0%和真实情况完全背离。给HTTP请求加一个简单的响应断言判断响应码是2xx是这个基础操作中最重要的一步。需要更严格时可以断言响应体里包含某个业务成功字段。例如接口返回JSON里code0表示成功那么就把断言设为“code0”这样业务失败也才会被计入错误率。这一步做完错误率才有意义。错误率与系统过载有很强的相关性。多数系统在接近容量拐点时错误率会从0突然上升到几十个百分点可能是连接超时、线程池拒绝、数据库连接耗尽。同时也会看到响应时间急剧飙升。如果压测中发现错误率先于响应时间出现异常通常说明系统已经出现排队溢出或者资源关闭。此时要尽快减小并发保护测试环境也方便排查具体错误类型。3. 资源维度CPU、内存、磁盘与网络的观测要点3.1 硬件指标的采样姿势性能测试只看应用返回的数据是不完整的还要同时观察被压测服务所在主机的资源消耗。因为只有资源指标能告诉你系统的瓶颈在哪里。常用工具有top、vmstat、iostat、sar、nmon。压测开始后每隔1到2秒记录一次采样持续整个测试周期。不能只看采样结束时的均值要观察变化趋势。CPU使用率要区分user、system、iowait。user高说明程序在密集计算通常是代码算法问题system高说明内核态消耗很大常见原因有系统调用过于频繁、上下文切换过多、网络包处理、中断等。iowait高表示CPU在等待磁盘IO往往意味着磁盘读写成了瓶颈。比如在压测中看到active线程不多但iowait一直超过50%就要去检查日志写入量、临时表空间、数据库落盘策略。内存指标不要只看总内存还有多少重点看是否大量使用swap。一旦发生swap内存页在磁盘和内存之间换进换出响应时间会出现几十毫秒到几百毫秒的毛刺。free命令显示swap的used不为0或者vmstat里si/so频繁出现较大的数值内存已经不够用了。频繁的GC和内存抖动经常被误判成CPU高实际上持续分配对象导致GC占用了大量CPU。磁盘IO在传统机械盘上比较好判断%util接近100%往往意味着饱和。换成SSD和NVMe之后%util的意义变得模糊因为SSD即使%util为100%也可能还有处理余量。更好的判断方式是看读写队列长度是否持续增长以及await时间是否明显高于正常基线。数据库服务器建议用iostat采集svctm和await应用服务器如果日志量很大也同样需要关注。网络指标容易被人忽略但高并发场景下网卡流量和长连接数量会成为隐藏瓶颈。观察sar -n DEV里的rxkB/s、txkB/s是否超过网卡带宽的一半检查网络连接数是否触及端口范围限制或文件句柄限制。压测中曾经遇到TPS到500就上不去服务端CPU和内存都很正常最后发现是TIME_WAIT连接数过多新连接建立失败。这类问题不采网络指标基本看不出来。3.2 数据库与应用服务器的隐藏指标很多接口瓶颈不在应用代码而在数据库。数据库层面需要关注连接数、慢SQL、锁等待、缓冲池命中率。MySQL可以用show global status查看Threads_connected是否接近max_connections如果连接数打满新的应用请求就会排队等待获取连接。慢SQL直接看慢查询日志锁等待则用show engine innodb status查看事务状态。压测过程中如果TPS平稳但响应时间有规律地升高很可能就是后台定时任务或者慢SQL占用了锁资源。应用服务器自身也有几个关键指标线程池活跃线程数、队列长度、GC次数与停顿时间。Java进程可以用jstat -gcutil观察YoungGC和FullGC发生的频率与耗时。如果Full GC频繁JVM所有应用线程都会短暂停止响应时间曲线上会出现明显的尖刺。线程池队列长度持续增长说明处理速度赶不上请求速度系统正在进入排队状态。Spring Boot默认的Tomcat线程池参数如果设置得不合理前面功能指标还没到容量拐点线程池就已经拒绝新请求了。这些内部指标不是压测报告必须全部列出的数据但它们服务于最终结论。比如发现响应时间从200ms涨到800ms有没有GC停顿数据直接决定了排查方向。没有资源数据就只能猜。3.3 资源指标与功能指标的联动分析性能分析的基本逻辑是功能表现出现异常时用资源指标来定位原因。反过来资源指标的异常也能帮助你预测功能指标的变化趋势。我总结过一个比较简单的对照思路。当TPS不再上升但CPU已经接近100%时最合理的判断是CPU已经是瓶颈系统所有线程都在忙于计算吞吐量到达硬件上限。当TPS上不去但CPU使用率不足30%时瓶颈不在CPU而在等待其他资源。常见的有数据库连接池等待、锁等待、下游接口调用慢、磁盘IO排队。这几类等待都会导致线程阻塞CPU自然空闲下来。当响应时间出现毛刺但平均响应时间正常时优先看GC停顿、锁等待、网络重传。三种问题的解决路径完全不同所以我才强调功能指标和资源指标必须同时采样否则你无法从毛刺形态判断原因。性能报告里如果只写“TPS最高达到800”信息量太少。应该写“TPS在并发300时达到峰值800对应CPU 70%平均响应时间350msTP99 800ms错误率0.05%数据库连接池使用率90%”。到这一步这个测试结论才具备参考价值。4. 容量维度并发用户数与SLA目标怎么定4.1 并发用户不是在线用户并发用户数是性能测试里被误解最多的概念。很多人以为系统有1000个在线用户压测时就设置1000个并发线程。实际上在线用户是“挂着系统但可能什么都没做”的人并发用户是“同时正在发出请求”的人。一个电商平台的10000个在线用户中真正同时在浏览、点击、下单的可能只有几百人。并发度这个比例需要根据业务模型估算不能拍脑袋。JMeter的线程数也不完全等于同时请求数。如果一个线程组设置了1000个线程Ramp-Up Period也给10秒那JMeter是在10秒内逐步启动这些线程。前5秒可能只有几百个线程在跑并不是1000个请求完全同时发生。如果需要精确模拟某个业务在同一个时刻有大量请求同时打出需要在Sampler前添加同步定时器Synchronizing Timer设置等待线程数等于预设并发数让这些线程同时被释放。做秒杀、抢购这类瞬发场景时必须用同步定时器否则压测请求会自然错开测不到真正的并发冲击。4.2 梯度加压与系统拐点判定想测出系统最大容量不能用固定并发跑一次就完事。我习惯于用梯度加压法从10个并发开始每5分钟增加10个或20个并发持续观察TPS、响应时间、错误率直到系统出现明显劣化。梯度加压的好处是能画出完整的容量曲线。初期并发增加TPS持续上涨随后增速放缓说明系统开始有排队继续加压TPS进入平台期说明已经到了吞吐上限再加压TPS不升反降同时错误率从0开始冒头这个位置就是系统的饱和点。饱和点对应的并发数称为最大并发用户数作为压力上限记录。最大并发数通常不适合作为长期稳定运行的推荐值更推荐把TPS出现增长趋势放缓时的并发数作为最佳并发。每个拐点不能只测一次。因为资源环境、数据缓存、数据库状态变化第一次跑出来的拐点可能受偶然因素影响。至少要独立复测一次两次结果趋势一致才能形成结论。正式容量评估场合我会把每次阶梯的并发、平均TPS、TP99、错误率记录到一张压测汇总表里一眼就能看出拐点在哪一段。4.3 从指标到容量规划的换算思路性能测试得到指标之后还需要把结论落到容量规划上。有一个经常用到的估算关系在稳定状态下吞吐量约等于并发用户数除以平均响应时间即TPS 并发数 / 平均响应时间。如果线上目标峰值TPS是500平均响应时间目标是0.2秒那么理论上需要的并发用户数大约是500 × 0.2 100。这个数字能让你大概知道压测时要把并发设置在哪里。但注意这个公式的前提是系统没有进入饱和区响应时间不会随着并发增加而剧烈变化。真实系统中并发升高后平均响应时间也会上涨所以实际规划不能直接在目标响应时间上反推而应该用压测曲线中接近目标TPS段的实测响应时间去估算。例如压测结果显示并发300时TPS为500平均响应时间450ms那么线上920TPS时并发就可能在500以上。预留30%到50%的buffer是容量规划的常见做法。5. 实操部分用JMeter跑一轮指标测试的要点5.1 测试前的线程组与监听器配置JMeter是最常用的压测工具之一但用不对地方很容易产出失真数据。线程组里需要设置线程数、Ramp-Up Period和循环次数。这三个参数加起来决定了实际施压负载。Ramp-Up Period我一般按每秒启动2到5个线程去设置比如100个线程Ramp-Up设30秒。如果Ramp-Up太短启动瞬间会对服务端造成一次流量冲击虽然能测出瞬发能力但平均指标会被拉低。脚本中的断言一定要配置完整。HTTP请求默认对状态码并不敏感即使收到500也会被当作正常响应。添加响应断言并勾选“Response Code”等于200或者检查响应体中的业务成功标记这一步直接决定错误率是否可信。压测时间也不能太短短到只有几分钟可能还没覆盖到缓存失效、连接池回收、线程池扩缩容这些动态行为。我建议稳定负载下至少持续10到15分钟容量类测试可以到30分钟。还有一点容易被忽略JMeter的图形界面本身也会消耗压测机资源。如果在线程数较大时用GUI模式跑压测大量采样数据和监听器绘图会让压测机CPU高企导致请求发出变慢最终结果被压测机自身拖累。正确的做法是把JMeter测试计划保存为JMX文件然后用命令行模式执行。5.2 聚合报告怎么看命令行压测结束后JMeter会生成CSV或JTL结果文件。用聚合报告监听器打开后有几个字段要重点关注。字段含义评估关注点Samples总样本数样本太少结论不可靠Average平均响应时间参考即可不作为主要达标依据Min / Max最小/最大响应时间最大值往往指向慢请求Std. Dev标准差越大说明响应时间越不稳定Error %错误率需要先确认断言配置无误Throughput每秒请求数和业务TPS区分理解90% Line90%的请求响应时间排除了极端值衡量大部分用户体验95% Line95%的请求响应时间目标通常看TP9599% Line99%的请求响应时间暴露长尾问题报告里数值高得离谱的Max和极高的99% Line是重点排查对象。它们通常不是平均负载造成的而是某个瞬间发生了GC、锁等待、网络重试、连接池耗尽。所以我会把压测机上的日志时间和服务端GC日志时间对齐找到尖刺出现的具体秒级窗口。5.3 命令行模式与辅助监控JMeter命令行执行的基本命令是jmeter -n -t test.jmx -l result.jtl -e -o report_dir。-n表示非GUI模式-l输出结果文件-e -o生成HTML报告。这个命令跑出来的HTML报告里包含TPS趋势图、响应时间百分位图、错误率趋势图比在GUI里打开聚合报告更直观。要分析某个时间窗口的数据可以加一个简单筛选也可以直接用Excel透视结果文件。压测机和服务端的时间最好是同步的否则定位问题时两边的日志对不上。压测过程中同步开启nmon或sar采集服务端CPU、内存、磁盘、网络指标结束后生成数据文件。这些辅助数据和JMeter报告之间的时间轴对齐整个问题链条就清晰了。超时时间的配置也需要注意。在HTTP Request Defaults里合理设置连接超时和响应超时比如连接超时3s、响应超时10s。没有超时会有一个致命的后果下游服务长时间挂起时JMeter请求会一直等待线程被占住错误率统计不出来同时服务端的线程池也可能被打满。只有超时连接被释放错误率才能反映真实的不可用状态。6. 常见问题与指标排查速查表6.1 响应时间抖动怎么排查响应时间平均不高但TP99高这种情况最常见的原因是偶发的外部依赖和系统内部暂停。按顺序排查查看GC日志看测试时间段内是否有Full GC查看数据库慢查询和锁等待检查压测机和服务器之间的网络是否存在丢包和重传查看应用日志中是否有网络超时、连接池获取超时的异常。还有一个容易被忽视的原因压测进程和后端的定时任务、日志归档任务叠加。比如每天早上两点有日志压缩任务恰好压测在这个时间点跑响应时间曲线就会出现周期性的尖刺。推荐的做法是压测前先观察一段时间的系统基线资源使用避开定时任务窗口或至少把定时任务单独记录出来。6.2 TPS上不去但CPU很低怎么分析CPU低但TPS停滞说明系统资源在等待而不是在计算。排查顺序可以这样先看数据库最大连接数和活跃连接数连接池打满时应用会阻塞在获取连接上再看应用线程状态用jstack抓线程栈大量线程BLOCKED说明锁竞争或连接池等待大量线程WAITING说明依赖下游响应再检查磁盘IO的iowait和await如果内存不足发生swapCPU也会被迫长时间等待。还有一个外部因素要考虑被压测服务是否依赖第三方接口或者配额受限。比如调用了外部限流为每秒100次的支付服务上游TPS再多也会被限制。此时需要看服务端线程是否大量处于RUNNABLE但没有任何进展配合日志中第三方调用的耗时就能看得出来。6.3 错误率突升的方向性判断不同错误类型指向的根因完全不同。如果错误率上升且错误样本中基本都是HTTP 500优先查应用日志和异常堆栈考虑代码bug、数据库会话中断、磁盘满。如果错误样本显示连接超时或读超时优先查服务端线程池、连接池、防火墙、负载均衡连接数。如果错误率上升但HTTP状态码都是200同时断言失败往往是断言条件和业务返回值不一致需要先确认返回体内容再判断是脚本问题还是真实业务失败。指标现象可能原因优先排查项响应时间整体上升负载超过系统容量资源使用率、队列、线程池TP99高但平均正常偶发GC、锁、网络抖动GC日志、慢SQL、重传错误率突升服务端异常/超时/限流应用日志、超时配置、连接数TPS停滞且CPU低等待资源和下游数据库连接池、锁、外部依赖TPS停滞且CPU高CPU计算密集应用算法、GC、系统调用磁盘IO高日志写满/SQL排序/内存交换磁盘队列、日志量、swap把这一套指标关联看下来性能测试就不再是甩一串数字给开发就结束的事情。它其实是一个不断定位、排除、收敛的过程。我个人实际体会是刚开始做性能测试时最容易犯的错就是只看JMeter报告里的基础字段忽略百分位和资源指标导致压测报告给出的结论既不完整也不可靠。后来养成“外部指标和内部指标同时记录、功能指标和资源指标联动分析”的习惯很多以前要靠猜才能找到的问题现在基本都能在测试阶段直接定位。如果你也想把性能测试做出真正决策价值先从把指标看全、看透、关联起来开始。
