很多团队做完一轮压测，图表看起来齐全，但结论仍然说不清系统到底能扛多少量、慢是慢在什么环节、再加压力会先崩哪里。LoadRunner的指标本身不难，难的是把指标按同一条因果链串起来解读，并把结论落到可复测、可验收的口径上。

　　一、LoadRunner性能测试指标有哪些

　　性能指标可以按响应、产出、负载、错误、资源五条主线归类，先把口径统一，再谈结果是否达标。

　　1、响应时间类指标

　　响应时间通常以事务或关键操作为统计对象，除平均值外，更需要关注90分位、95分位、99分位等分位指标，用来识别长尾与偶发慢请求。若只看平均值，少量极慢请求很容易被掩盖，业务体验却会明显变差。

　　2、吞吐量与交易速率类指标

　　吞吐量关注单位时间内处理的数据量，交易速率关注单位时间内完成的事务数，例如每秒事务数，这两类指标共同回答系统到底能产出多少有效处理能力。它们需要和响应时间一起看，单独看吞吐量高并不代表系统稳定。

　　3、并发与负载强度类指标

　　并发不只是设定了多少虚拟用户，更关键是同一时刻有多少用户在真正发起请求，包含Running Vusers与实际活跃交易节奏。脚本的思考时间与Pacing会显著影响有效并发，容易造成看似人数很多但压力并不密的错觉。

　　4、错误与稳定性类指标

　　需要统计HTTP错误、业务校验失败、超时、断连、重试等，并给出错误率在不同负载阶段的变化趋势。错误一旦上升，响应时间与吞吐量可能出现失真，因为失败请求并不等于系统处理得快。

　　5、资源与瓶颈类指标

　　包含CPU、内存、磁盘读写、网络、连接数、线程池、队列长度、数据库等待与GC等，用来把性能拐点与资源拐点对齐。资源指标的价值在于定位第一限制因素，而不是单纯证明机器忙不忙。

　　二、LoadRunner常看的响应时间吞吐量并发数怎么解读

　　三条曲线要放在同一时间轴上解读，先确认口径一致，再用变化趋势判断系统是否进入排队与饱和。

　　1、先把响应时间口径说清楚再对比

　　需要明确是事务级响应时间还是单请求响应时间，并确认统计是否包含思考时间与客户端等待。建议同时输出平均值与95分位作为主口径，并在报告里写清采样范围与稳态窗口，否则不同轮次很难对比。

　　2、用分位指标判断长尾比看平均更可靠

　　平均值不高但95分位明显抬升，通常意味着少量请求被锁等待、队列排队、外部依赖抖动或垃圾回收停顿拖慢。长尾一旦在高负载阶段放大，用户体感会先崩，哪怕平均值仍然好看。

　　3、吞吐量要和响应时间一起判断是否到容量边界

　　当并发上升时吞吐量也上升且响应时间稳定，说明系统仍有余量。若吞吐量趋平但响应时间开始陡升，常见是服务端进入排队状态，继续加压只会把等待拉长。若吞吐量下降且错误率上升，往往是系统开始超时、拒绝或触发保护机制。

　　4、并发数要区分设定并发与有效并发

　　设定的Vuser数量只是压力源规模，有效并发取决于事务执行时长、思考时间与Pacing间隔。思考时间长或Pacing过松时，Running Vusers很高但同一时刻真正发请求的人并不多，吞吐量上不去并不一定是系统弱，可能是脚本节奏不够密。

　　5、用拐点来判断系统从可用到拥塞的转折

　　把Running Vusers、吞吐量、事务响应时间放在同一图上观察，当Vusers继续上升而吞吐量不再增长，同时响应时间曲线出现明显折线向上，这通常就是容量拐点附近。拐点之后再加压，结果往往是长尾扩大、错误增加、吞吐反而回落。

　　6、把三项指标落到验收阈值才算解读完成

　　响应时间需要对齐业务SLA，建议以95分位作为主验收口径并标注可接受上限。吞吐量需要对齐目标峰值交易量与峰值持续时长。并发数需要对齐真实业务的在线与活跃比例，否则图表再漂亮也可能与生产负载不一致。

　　三、如何用指标把压测结论写得可复测可落地

　　指标解读最终要服务于复测与整改，建议用固定窗口、固定口径、固定复现动作把结论写成可执行清单。

　　1、先把场景条件写成可复测的基线

　　在Controller中确认Vuser分配、升压节奏、持续时间、思考时间与Pacing的最终值，并把这些条件写进报告首页。没有基线条件的结论不可复现，后续复跑也无法解释差异。

　　2、先看错误再看性能曲线

　　在Analysis里先汇总错误类型与错误率的变化，再解读响应时间与吞吐量。若错误率在高压阶段抬升，需要先说明失败占比与失败原因，否则响应时间下降可能只是因为大量请求提前失败。

　　3、只截取稳态窗口做核心对比

　　把预热阶段与收尾阶段剔除，只选稳定施压的时间窗口输出平均值与分位值、吞吐与交易速率、有效并发等核心数字。稳态窗口固定后，跨版本对比与跨环境对比才有意义。

　　4、把性能拐点与资源拐点对齐定位第一瓶颈

　　先标出响应时间陡升或吞吐量趋平的时间点，再对照服务器监控，看是CPU先满、还是连接数先耗尽、还是磁盘与网络先抬升，或是数据库等待先增大。第一瓶颈定位清楚后，优化优先级才不会跑偏。

　　5、把结论写成整改动作与验证方式

　　将问题拆成具体动作，例如需要优化的接口与SQL、需要调整的连接池与超时、需要扩容的资源项、需要补齐的监控指标，并为每一项写明复测方式与验收口径。这样下一轮压测只要复跑同一场景，就能客观判断改动是否有效。

　　总结

　　LoadRunner的指标可以用响应时间、吞吐量、并发与错误资源这几条主线串起来看，其中响应时间建议以分位指标识别长尾，吞吐量需要和响应时间共同判断是否进入排队，并发数必须区分设定并发与有效并发。把场景条件与稳态窗口固定，再用拐点对齐资源瓶颈，最后把结论落成可行动的整改与复测口径，压测报告才算真正可用。