前言
今天的场景设计需要说明两个前提条件:
- 这些业务都是实时的业务,不涉及批处理、大数据等业务。
- 因为本篇着重讲场景的设计和具体项目的操作,所以不加系统资源的分析,避免信息混乱。
在这个场景设计中,首先,我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。
其实我们在做项目的时候,经常会这样制定一个统一的响应时间指标,这样做也不是完全因为懒,更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道,这显然是不对的,因为业务不同,响应时间指标也应该不同,合理的做法是给出每个业务的响应时间指标。下面我们还会遇到响应时间定得不够细致的问题。
有了这个列表,下一步就是做基准性能测试了。
一、基准性能场景
有很多人做接口测试的时候,觉得接口的 TPS 真是高呀,于是就按照最高的 TPS 跟老板汇报。但我们一定要知道的是,接口的 TPS 再高,都无法说明容量场景的情况,除非这个服务只有这一个接口,并且也只为了测试服务,这时就不必有混合的情况了。
首先,我们要知道,每个业务在系统中的最大容量是多少。那么接下来,我们用上面的业务一个一个地做基准,看看结果如何。
业务1
场景执行时长:17 分钟。
先看 Statistics。
很多人喜欢用这个表中的数据来做报告,特别是 90th pct、95th pct、99th pct。我不是说不能用,但是,我们要先知道这个场景是什么样,再来确定这些值是不是可以用。
从上图来看,TPS 达到 573.24,平均响应时间是 109.83ms,发送字节很少,这里都没统计到,接收字节 966.22KB/sec,这个值也非常低,最小响应时间 43ms,最大响应时间 694ms。
但是!这能说明什么呢?什么都说明不了呀。是好是坏?不知道呀。所以我们还需要看其他图。
我们先看一下线程图。
以每分钟 15 个用户的速度往上递增。
对应的响应时间图是下面这样的。
随着用户的增加,响应时间一直都在增加,显然瓶颈已经出现了。
我们再结合 Statistics 表格中几个和时间有关的值来想想一想,90th pct、95th pct、99th pct、平均响应时间还可以用吗? Statistics 的平均响应时间是 109.83ms,但是你从响应时间图和线程图比对就可以看到,在不同的线程阶梯,响应时间是有很大差别的。所以 Statistics 中的响应时间都是针对整个场景来说的,然而在梯度加压的过程中,用 Statistics 中的数据是不合理的。
接着我们再来看下 TPS 图:
我们可以从 TPS 图上看到,最大 TPS 能达到 680 左右。我再啰嗦一句,请你不要再用所谓的”最大 TPS 拐点“这样的描述来说明 TPS 曲线,我在第 6 篇文章中也说过,性能的衰减是逐步的(也有突然的情况,那是非常明显的性能瓶颈了),在最大 TPS 出现之前,就已经可以判断瓶颈是否出现了。
结合上面四个图,我们就有了如下的判断:
- 场景是递增的。
- 压力线程上升到 55(第四个阶梯)时,TPS 达到上限 680 左右,但是明显的,性能在第三个阶梯就已经接近上限了,
- 在压力线程达到 55 时,响应时间达到 85ms 左右,这个值并不高。
除此之外,其他的似乎不需要我们再做什么判断了。
也许这时候你会想问,那么瓶颈在哪里呢?总有人看到现象就想知道结果。但是这一次呢,我不打算满足这样的好奇心,因为本篇只是为了讲场景的逻辑,而不是瓶颈的分析。哈哈。
业务 2
从业务 2 开始,我们不做啰嗦的数据解释了,只说明一下关键点。我们看图。
Statistics 图:
线程数: