在做完压测之后，想要清楚了解系统可以接受多少量，慢是慢在什么环节等，需要将指标按同一因果链条串起来解读，并将结论落到可复测、可验收的口径上。接下来我们就一起来看下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分位作为主验收口径并标注可接受上线。吞吐量需要对其目标峰值交易量与峰值持续时长。并发数量对齐真实业务的在线与活跃比例。

以上便于关于loadrunner性能测试指标的相关内容，想要获取更多内容可以随时与我们取得联系。