[性能测试day2]常用指标
作者：互联网
常用性能测试指标
主要指标：并发用户数、响应时间、最高吞吐量、极限吞吐量、成功率、性能拐点、系统稳定性、系统健壮性、低吞吐量和网络小包
并发用户数
- 业务层面：实际使用系统的用户总数
- 后端层面：同时向服务器发送请求的数量
- 潜在用户数：拥有系统账号的用户总数
- 业务并发用户数：登录了系统
- 实际并发用户数：真正对服务端产生了压力。取决于业务并发用户数+用户行为模式（可能是停在界面未操作/进行了服务端相关操作等…）
分析并发数的关键:分析用户的行为模块
- 例如：准点活动、商品秒杀、常规时间段…
- 根据系统日志进行分析
- 行业类似系统的统计、多方收集到的系统用户信息
响应时间
- 前端展示时间：客户端收到服务器返回的数据后，渲染页面所消耗的时间
- 系统响应时间：发起请求到处理完成的时间(一般更关注该项)
- 标准：建议是TP95或以上，一般读不超过200ms，写不超过500ms
最高吞吐量
- ThroughPut TPS 在目标响应时间要求下，系统可支撑的最高吞吐量。
- 计算方式：requests/second、pages/second（考虑HTTP或业务层面） bytes/second（考虑系统/网络层面）
极限吞吐量
- 阶梯式增加并发压力，找到系统的极限值。比如：在成功率 100% 的情况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量。
成功率
- 在关注QPS和响应时间的同时，还要关注成功率。如果QPS和响应时间都满足性能要求但请求成功率只有 50%，用户也是不会接受的。
性能拐点
- 服务的性能临界点，当超过临界点时，吞吐量非线性下降，响应时间指数级增加，成功率降低。
找到出现性能拐点的主要原因： 基于性能拐点主要原因设置高危性能报警线。此为高风险注意事项，因为一旦达到性能拐点，有可能会出现雪崩现象，造成极其严重的事故。
系统稳定性
- 保持最高吞吐量（目标响应时间下的最高吞吐量），持续运行 7*24 小时。然后收集 CPU，内存，硬盘/网络 IO，等指标，查看系统是否稳定，比如，CPU 是平稳的，内存使用也是平稳的。那么，这个值就是系统的性能。
系统健壮性
- 做 Burst Test。用第二步得到的吞吐量执行 5 分钟，然后在第四步得到的极限值执行 1 分钟，再回到第二步的吞吐量执行 5 钟，再到第四步的权限值执行 1 分钟，如此往复个一段时间，比如 2 天。收集系统数据：CPU、内存、硬盘/网络 IO 等，观察他们的曲线，以及相应的响应时间，确保系统是稳定的。
低吞吐量和网络小包
- 低吞吐量可能会导致 latency 上升，比如 TCP_NODELAY 的参数没有开启会导致 latency 上升（详见 TCP 的那些事），而网络小包会导致带宽用不满也会导致性能上不去，所以，性能测试还需要根据实际情况有选择的测试一下这两个场景。
标签：常用,并发,day2,性能,系统,响应,吞吐量,测试,成功率 来源： https://blog.csdn.net/likeAcat_94/article/details/113992395