性能场景之压测策略设计

Posted 2021-05-26 zuozewei

文章目录

• • 一、前言
  • 二、单业务压测策略
  • • 1、策略一
    • 2、策略二
    • 3、策略三
    • 4、综述
  • 三、混合场景压测策略
  • • 1、LoadRunner
    • 2、Jmeter
  • 四、一个业务的复杂场景
  • 五、小结

一、前言

性能场景应该说是在性能测试中非常关键的一个环节。

但是在我接触过的同学及公司之中，还是发现有很多人并不是非常关注性能场景中的细节。

二、单业务压测策略

今天就只写一个地方，就是压测策略。压测策略多种，设置也是五花八门。比如说如下几种（用 jmeter 举例，其他工具仅配置方法不同）。

1、策略一

• 在这个策略中共有 100 线程（在 loadrunner 中称为vuser），每 30 秒增加 10 个用户，且递增的时间间隔为 6 秒。也就是说，这 30 秒内的 10个 用户是以每次 2 个用户增加的；
  每增加 10 个用户之后，持续 60 秒；

• 停止线程的时候是每秒停 5 个用户，直到停完为止。

• 场景在一开始启动时，并没有启动线程，也就是说在前 6 秒内是没有线程启动的，6 秒后 2 个线程启动。

2、策略二

在这个策略中，我们可以看到如下内容：

• 100 个线程同时启动；

• 持续 600 秒；

• 再同时停止；

3、策略三

这个策略是：

• 先启动 10 个线程；

• 接着每隔 10 秒启动 10 个线程，直到 100 个线程启动完；

• 持续 600 秒；

• 然后每隔 10 秒停 10 个线程。

4、综述

举这三个策略为例吧。因为比较典型。什么时候应该用什么样的压测策略呢？这才是关键的问题。

首先，要定义的是测试的目标。如果是在系统的最大容量并不清楚的情况下显然第一种压测策略最为合理，因为在压力逐渐增加的过程中，可以看到响应时间和 tps 之间的关系。

那么第三个压测策略和第一个又有什么区别呢？之所以列出第三个策略是因为第一种使用的人非常少。而第三种相对比较多。目标和第一个是一样的。只是这个时候要把握好递增线程的幅度。

我建议的是在不清楚系统最大 TPS 的情况下，最好使用第一种策略。因为使用第三种，可能需要反复试好几次。

第二种压测策略又有什么讲究呢？我碰到使用第二种策略的人是比较多的。并且大部分是不知道这种策略带来的结果是什么。

通常情况下，这种压测策略只用在秒杀、竞拍之类的场景中。有人说应该用集合点来实现这样的策略。请注意，如果不是在分析了具体场景之后，明确知道应该用多少的压力来做这样的场景，最好不要用集合点。

这里面要有个计算的过程才可以。

有人喜欢用第二种压测策略来实现 100、200、300、400 这样单个场景递增的方式。其实在实际的应用场景中，这是短暂出现的场景。所以这种方式仅是在测试峰值的那一刻，这种方式在实际的性能场景中其实不是那么有必要，应该说过于简化了本来的应用场景。

三、混合场景压测策略

上面写的压测策略是对单个业务来说的。

每次在做项目的时候，我都说起过，要先做基准测试。

之前我看到有人把基准测试定义为脚本的基本验证。从概念上说，这种描述是完全错误的。这个问题可以留待后面再展开来说明。

对于多业务脚本混合的场景来说，每个业务脚本的设置就成了必然要考虑的事情。

所以在这之前需要的是对单个业务特点进行分析，分析到可以设置出符合真实业务场景为止。这一点非常关键，非常关键。 如果做不到和真实业务场景符合的话，性能测试分析优化的整个过程也仅是查查系统的代码问题、环境问题、配置问题、数据问题、架构问题等等。

有人说，这样已经足够了呀。

可是，性能项目的实施仅仅是为了找问题吗？即使找出问题，能让系统支撑得住真实业务场景吗？这个问题是大部分做性能测试的人不敢回答的。

所以场景设计的重要点在于可以把真实业务场景重现出来，进而分析系统容量是否满足业务要求。

混合场景在不同的工具中有不同的设置方法。

1、LoadRunner

对于 LoadRunner 来说，在设计思路上，它对场景的设定是全局的。有种所有业务都由我掌控的感觉，就是很霸道的全局设置思路，每个业务脚本可自己发挥的空间。

我是很认可这种设计思路的，就是对整个场景要有明确的掌控感。

只是缺乏灵活性。

还好在 LoadRunner 中有 Group 可以弥补这个灵活性的欠缺。

2、Jmeter

对 Jmeter 来说，各个设置都是松散的，线程组的设置也都是单独的，想怎么玩怎么玩。

所以对混合的场景设置来说，Jmeter 这样的工具才是对个人素质要求更高的。

像上图中所展示的，每个线程组可以有不同的发起、持续、停止策略。

不管工具上如何设置，最核心的内容还是如何把真实场景复现出来，而这一点是工具不可能告诉你的。不管是现在的云性能测试工具还是单独的性能测试工具，在这些内容的深化上都存在着很大的发展空间。

性能测试之所以人在其中的作用很大，也就是在这些灵活的部分。

之前我看到有些自研发的工具中给一个简单的脚本，即可以发出上万上亿的请求，并且称之为场景。那是非常片面的一种场景，或者说目标不是复现真实业务场景。

四、一个业务的复杂场景

前面提到了压测策略中的一些内容。

现在我们来看一下，一个业务的复杂场景设置。

是的，你没有看错。就是同一个业务的复杂场景设置。

后面再说多业务的复杂场景

分析了业务之后，如果这个业务有不同的高峰时段，可以有不同的设置方式。

比如下面这样：

每小时内的请求量各不一样。

对于这个业务的性能执行场景应该制定这样的压测策略。

配置方式在同一个工具中可能都不一样。

可以在一个线程组中实现，也可以每个小时的业务量有用一个线程组。

这样设置出来的场景才和实际的场景相似。

有人可能会觉得直接设计峰值那个小时内的场景就可以了。

其实不止。

因为还有些时段需要做压力补充，像批处理的业务就要加进去。

另外资源的 open、close 也会是问题出现的点。

五、小结

在细节的控制中才见真功夫。

性能是一门艺术。