可用性测试效能指标（服务端压测指标如何评估）

可能很多新手QA、RD同学，对服务端压测一直没有系统的认知，印象停留在使用压测工具如Jmeter对单接口发压，调整线程数和循环数来制造不同压力，最后计算一下TPS和成功率等就完事了？网上虽然有不少压测相关的文章，但多数是压测工具的入门级使用，有的是压测流程和指标的简单解释，或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍这些文章要不缺少系统性阐述，要不过于抽象不好理解，对没怎么接触过压测的同学看起来还是不太理解，本文就重点从压测指标如何评估这个角度出发，现在小编就来说说关于可用性测试效能指标?下面内容希望能帮助到你，我们来一起看看吧!

可用性测试效能指标

可能很多新手QA、RD同学，对服务端压测一直没有系统的认知，印象停留在使用压测工具如Jmeter对单接口发压，调整线程数和循环数来制造不同压力，最后计算一下TPS和成功率等就完事了？网上虽然有不少压测相关的文章，但多数是压测工具的入门级使用，有的是压测流程和指标的简单解释，或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述，要不过于抽象不好理解，对没怎么接触过压测的同学看起来还是不太理解，本文就重点从压测指标如何评估这个角度出发。

压测流程

完整的压测流程一般包含下面几个步骤：

1、压测目标的制定

2、压测链路的梳理

3、压测环境的准备

4、压测数据的构造

5、发压测试

6、瓶颈定位及容量微调

7、压测总结和报告

压测指标

列举一些常用指标，并不一定都需要关注，根据业务考虑指标的细化粒度。

QPS：Query Per Second，每秒处理的请求个数

TPS：TransactIOns Per Second，每秒处理的事务数，TPS <= QPS

RT：Response Time，响应时间，等价于Latency

RT分平均延时，Pct延时（Percentile分位数）。平均值不能反映服务真实响应延时，实际压测中一般参考Pct90，Pct99等指标

CPU使用率：出于节点宕机后负载均衡的考虑，一般 CPU使用率 < 75% 比较合适

内存使用率：内存占用情况，一般观察内存是否有尖刺或泄露

Load指标：CPU的负载，不是指CPU的使用率，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，表示CPU的负载情况，一般情况下 Load < CPU的核数*2，更多参考链接1和链接2

缓存命中率：多少流量能命中缓存层（redis、memcached等）

数据库耗时：数据库就是业务的生命，很多时候业务崩掉是因为数据库挂了

网络带宽：带宽是否瓶颈

接口响应错误率 or 错误日志量

这里要说明一下QPS和TPS的区别：

QPS一般是指一台服务器每秒能够响应的查询次数，或者抽象理解成每秒能应对多少网络流量

TPS是指一个完整事务，一个事务可能包含一系列的请求过程。举个，访问一个网页，这是一个TPS，但是访问一个网页可能会对多个服务器发起多次请求，包括文本、js、图片等，这些请求会当做多次QPS计算在内，因为它们都是流量性能测试中，平均值的作用是十分有限的，平均值代表前后各有50%的量，对于一个敏感的性能指标，我们取平均值到底意味着什么？是让50%的用户对响应时间happy，但是50%的用户感知到响应延迟？还是说50%的时间系统能保证稳定，而50%的时间系统则是一个不可控状态？

平均响应时间这种指标，只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子，人均财富这个概念有多沙雕相信大家也明白，19年有个很搞笑的新闻——腾讯员工平均月薪七万，明白平均值多不靠谱了吧。下图是现实世界中一个系统的响应时间柱状图，RT在前20%的请求数较少，但是因为耗时特别短（拉高了均值可能是命中缓存，也可能是请求的快速失败），而大多数RT是在均值之下，那才是系统的实际性能情况。

均值并不能反映实际情况，所以说，我们不应看最好的结果，相反地，应该控制最坏的结果，用户用得爽他不保证会传播好口碑，但是用户用到生气他保证变为键盘侠肆意大骂，这也是为什么平均值无法带来足够的参考，因为happy的结果蒙蔽了我们的双眼，平均值在压测中丢失太多信息量。

总结一下，较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的，比如：99%的响应在500毫秒内返回，其中成功率为99.99%。

根据这个方针，可以得到一些测试思路：

1、在响应时间的限制下，系统最高的吞吐量（这里不对吞吐量做严格定义，当成是QPS或TPS即可）

2、在成功率100%的前提下，不考虑响应时间长短，系统能承受的吞吐量

3、容忍一定的失败率和慢响应，系统最高能承受的吞吐量（95%成功率，前95%的请求响应时间为xx毫秒时的最大QPS）

4、在上面的场景下还要考虑时间和资源，比如最高吞吐量持续10分钟和持续1小时是不一样的，不同的时间持续长度下，机器资源（cpu、内存、负载、句柄、线程数、IO、带宽）的占用是否合理

目标预估

压测开展前是需要有目标的，也就是有期望的性能情况，希望接口或系统能达到的性能预期，没有目的的压测是浪费人力，下面给出几种目标预估的方法。

历史监控数据

已经上线并且有历史监控数据的接口，可以查看历史数据，找出峰值QPS和PCT99。 若接口A已经上线并且做了监控，在经过某次大活动或者上线时间足够长后，存量监控数据就可以使用了。

类比

新接口或者线上未监控的接口，不存在历史数据，但存在类似功能接口的历史监控数据，可以通过类比得出压测的目标。 假设上一年淘宝双十一下订单接口QPS=x，RT=y，这一年天猫平台整起来了，双十一活动与上年淘宝双十一活动场景类似，也沿用QPS=x，RT=y的目标（例子不严谨，理解即可）。

估算

新接口或者线上未监控的接口，不存在历史数据，且不存在类似功能接口的数据可供参数考，此时需要估算峰值，常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。

top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)

RT如无特殊要求，一般采用默认值：

单服务单表类，RT<100ms

较复杂接口，RT<300ms

大数据量或调用链较长的接口，RT<1s

-1：电商秒杀活动，预估同时有1000w人参与，简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散，再加上nginx等webserver做了20%几率拒绝请求的策略，所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最终压测目标为400w/s的QPS。

-2：电商全天低价抢购活动，屠龙宝刀，点击就送，一刀99级，emmmmm跑题了。根据8/2原则，预估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，估算接口峰值QPS = 活动全天接口PV / (4*3600s)。

其他

除了前面说到的情况，肯定还有一些我们无法下手的三无接口，无参考、无预估、无历史数据，这时候只能一点一点来，慢慢把压力提上去的同时收集数据，最终得出接口的最优处理能力。

,