性能场景之业务模型在性能执行场景中的具体实现逻辑

• 背景

这里还有往下的一步就是如何把这个业务模型配置到工具中去。这个步骤其实在我写第二个专栏的时候，在第6章的最后是写了具体的操作过程的。后来我想这个应该是所有性能测试工程师的日常工作内容，所以从难度和重要性上来说，都过于平常了，而性能测试工程师对这一过程应该是非常熟悉的，没必要再啰嗦一遍，就像性能工具的基本操作一样，所以就没放到专栏上去。

但是随着在群里、私信里、企业内训里被问到过多次这个知识点，我才发现，绝大部分的性能测试工程师，并不清楚统计出的业务模型如何具体配置到压力工具中，从而导致了容量场景的结果和统计出的业务比例模型并不一致。

甚至大部分人，都不会把容量场景结果中的业务比例模型和统计出的业务比例模型做比对。

从而导致了一个严重的问题，就是容量场景根本不能严格遵循生产业务比例模型，那就意味着，容量场景即使是非常好看的结果，但是也无法回答生产环境中相应的场景会不会导致生产问题。

那这个性能项目就等于是瞎做一通。

所以，这次我就把这个问题从前到后说明白。

• 系统架构

因为业务模型中的比例对应的请求数经常是很多人困惑的重点，所以这里我要先把调用路径列清楚。

我们先来说一个最为直观的系统调用逻辑。在这个调用过程中，我们有四个系统。

压力从gateway进来后，到系统A，系统A调用系统B通过feign调用，后面调用都一样，不走gateway。

• 业务模型

有了架构，就得有具体的业务模型了。在这里我们设计一些比例关系。在这里，我先列出业务级的接口和相应的比例来。

注：这个比例如何得到在本文开始提到的两个文章中都有描述，不清楚的可以去回顾一下。也可以看一下《如何使用 Python 统计分析 access 日志？》。

但是只有业务接口还不够，我们还要再细化下去，根据接口和架构，我们再加上访问路径。

同时，还有几点要说明的是：

1. 每一个业务接口在调用时，都会在经过的系统中产生一条请求，同时插入一条记录。
2. 接口都是串行调用。比如说：Pabcd接口，就穿过系统A - 系统B - 系统C - 系统D，这一点很重要，所以再次强调。

再次丰富上面的表格如下：

上面的表格是每个业务接口只调用一次在各系统中产生的请求数和DB记录数。

那如果总共调用了100次，并且每个业务接口都按比例产生了请求。那每个系统产生的请求数和DB记录数是多少呢？我们计算一下。

到这里，所有的逻辑还是非常清晰易懂的，对吧。

现在我们就得来设计脚本了。

• 脚本设计

针对这个业务比例，我们有两种策略来设计脚本。

策略一：所有业务接口之间都是独立的，没有任何业务逻辑。

那显然，我们把每个接口单独控制比例就行了。在jmeter中可以设置如下：

就是针对每个业务接口都放到一个Throughput Controller中。比例设置和上面的表格中一致。如下所示：

这时，如果我们运行100次迭代，那显然每个接口会严格按设置的比例来执行。来执行下看，线程组配置如下：

我用1个线程迭代100次。看看执行结果：

显然各个接口是按照我们设计的比例来执行的。

那线程组如果不这样设置呢？比如说，这样：

10个线程，每个线程跑10遍。得到的结果如下：

你会看到完全一样的比例。

这时在后台每个系统中的请求和记录数是多少呢？如下表所示：

这是必然的结果。

那可能有人又说了，那如果不限定迭代次数，而设置duration呢？我们再来设置一下。