压力测试核心性能指标及行业标准

在做压力测试时，新手测试人员常常在看报告时倍感压力：这么多性能测试指标分别是什么意思，应该达到什么标准？

本文将结合实际压测报告，帮助您快速理解压测时的主要性能指标，了解如何解读该指标以及通常情况下应该达到的标准。

优测在线压测平台报告示例

指标1：响应时间

性能测试过程是模拟用户真实视角的请求过程。一个请求的“响应时间”指的是从开始跟被测服务建立连接、发送请求内容、再等待服务响应、最后完整接收回包的整个时间长度。

这里需要注意的是，通常研发人员考量的接口响应时间，是从服务接收到请求后到发出请求的时间长度，这其实是性能测试报告内“响应时间”的“子集”。

平均响应时间作为报告的重要的指标之一，计算方法是计算整个压测过程中全部请求的响应时间平均值。

除了平均响应时间，压测人员通常还会关注最小、最大、90%、95%、99%响应时间。计算方式是将所有请求的响应时间按从小到大排序，其中最小、90%、95%、99%和最大分位的数据，即上述指标的值。例如，95%响应时间，意味着整个压测过程中95%的请求的响应时间都小于该值。

响应时间应该如何分析，在实际业务中应该达到什么样的标准呢？

图片为腾讯某真实线上运营活动接口的压测报告截图，在模拟5000用户并发压测5分钟期间，平均响应时间为48毫秒，失败率低于1%（该项指标符合该业务预期）。

压测人员需要就趋势图中偶发超长响应时间进行分析，联动开发人员根据traceID跟踪分析具体原因即可。

响应时间与客户体验息息相关，有说法称，当页面的加载速度大于1秒时，搜索引擎SEO会对网站进行降权处理。

虽然响应时间并没有严格的通用标准，但这里我们给一些行业通用的标准给大家做一个参考。

• 对于大部分互联网行业业务来说，接口的平均响应时间普遍优于其他行业，核心接口响应时间通常小于200毫秒，普通接口小于500毫秒，部分特殊接口也以小于1秒为佳。当超出相应标准时，需研发人员对服务进行扩容或性能优化。
• 对于非互联网行业来说，响应时间标准要放宽一些，但通常建议核心接口响应时间小于500毫秒，普通接口小于1秒，特殊接口也不要超过3秒为佳，否则将较大程度影响用户使用体验。

指标2：吞吐量（TPS）

吞吐量度量了单位时间内被测服务可以处理多少请求，所以是服务性能的重要指标。压测过程中吞吐量通常使用TPS进行度量。

什么是TPS呢？TPS的全称是Transaction Per Second，也就是被测服务每秒处理的事务数TPS的计算方式，是用压测时间段内的总事务数除以压测总时长秒数，即可得到每秒处理事务数。

在压测过程中，优测压测平台会每秒计算一次当前这一秒的TPS，压测过程结束后，其中最小和最大的即最小和最大TPS，求均值即可得出平均TPS。

这里需要注意的是，TPS的指标必须结合压测时配置的并发线程数，即模拟用户数一起分析。在被测服务未达瓶颈的时候，线程数越大，TPS越大。举一个例子，平均响应时间是200毫秒的某业务，假如仅模拟1用户数发压，那么TPS等于5，显然并不代表服务的极限吞吐量水平。

通常情况下，我们会通过不断增加线程数，在错误率符合预期的前提下，探索TPS的上限，作为当前部署配置下的服务吞吐量指标。

那么报告内的TPS趋势图该如何分析？该达到什么样的标准呢？

图片为某业务接口的压测报告截图，模式为梯度增压模式，也被称为“摸高”模式，即通过逐步增加并发量，探索被测服务吞吐量瓶颈。如图所示，在并发数第一次上升的过程中，TPS吞吐量大幅提升，但在后续“爬坡”过程中，吞吐量基本保持平稳，这说明被测接口的吞吐量已达到瓶颈。

TPS通常根据业务需求来进行设定，如分析该业务历史真实线上业务数据的峰值，乘以一定的buffer作为此次压测目标。或者对于暂未上线的活动或者功能，根据产品或运营人员预估的峰值请求数乘以一定的buffer作为此次压测目标。Buffer值通常为1.5-3倍，视风险情况而定。

这里我们也给出一些常见业务类型的TPS情况，仅供参考。电商或大规模的运营活动，如秒杀等场景，因为瞬间高峰值请求情况，TPS通常能达到百万级别。普通的互联网业务，通常吞吐量根据业务重要程度不同，在1万至10万之间。对于非互联网行业产品或小规模系统，因为用户量不大，TPS通常在5万以下。

指标3：失败率

失败率是性能测试过程中最好理解也是最重要的指标。

失败率的计算方法，是用总失败请求数除以总请求数。通常标准为比较严格的要求100%成功，或者相对可接受的失败率低于1%，也就是100次请求业务中，有一个用户会遭遇失败。

需要注意的是，很多压测人员会简单的使用http响应码作为判断标准，200即成功，其他即失败。在实际经验中，经常会出现响应码是200，但响应结果不符合预期的情况。所以需要压测人员根据业务逻辑，配置详细错误断言和描述，精准评估失败率。

总结：

不管是哪个指标，其实最重要的不是对指标本身是否达标的度量，而是通过指标评估被测系统是否达到预期，以及对具体问题的分析和定位。需尽可能通过查看日志、链路追踪等方法，定位问题根源并解决。

如下图实例，根据错误请求的具体请求和响应信息，分析具体原因。并通过链路追踪，精准定位问题。