性能实战之容量场景设计

之前文章说过补一篇容量场景设计，虽然看过很多文章，但自己实现起来却很费劲。

容量场景

什么是容量场景？

容量场景指所有业务通过一定比例混合的场景，也是代表真实的用户级场景。

什么是业务模型？

真实的用户场景也就是生产业务场景，而把生产业务场景通过建模方式得到的模型就是业务模型。

于是，业务模型决定了容量场景的有效性。那怎么得到这个业务模型？

高楼老师提到，首先得明确当前场景是要模拟历史业务场景，还是未来业务场景。未来业务场景需要业务团队给出评估，而历史业务场景最好要有历史业务数据支撑。

我这里是模拟历史业务场景，所以第一轮性能测试没有做容量测试，这次是有了线上运营数据后，我才开始的做的容量测试。

业务模型分析

现在历史数据有了，我们可以按照以下步骤来得到业务模型。

统计生产业务量

我们没有ELK这种顺手的日志统计系统，但能从nginx访问日志中抽取。

由于我们主要流量是虚拟商品售卖业务，日常流量不大，通过命令查看售卖当天业务分布情况，如下命令

cat xxxx.log|awk '{print $4}' |cut -c 2-18|uniq -c    # $4是指以空格分割的第4个元素，根据实际nginx日志格式来，修改cut -c部分可以按时、分、秒来统计

统计峰值TPS的业务场景

通过上述命令，得到当天10-11点为峰值流量（也能对应售卖时间），但由于日志中接口路径存在多种格式，使用命令无法完全过滤，写了个python分析脚本，结果如下：

当天流量情况

峰值10-11点情况

通过上图可知：

• 10-11点峰值流量几乎占当天流量的一半，而且各业务流量分布基本一致，即用该业务模型做一个容量场景即可。
• 得出了每个请求的请求数占总数的比例，存在一些少量请求的接口（0.1%以下）。
• 接口中存在调用第三方的接口，比如支付宝、微信支付。

由于jmeter中吞吐量控制器的百分比单位最小保留一位，即0.01%是设置不了的。所以要么过滤掉，要么一起合并。

严格来说，可以合并到一个事务，然后比例选择执行，但考虑到样本太少，我当时这里是过滤掉的，如下图：

于是我们得到了各接口比例，而部分接口涉及第三方，可以做mock，也可以改造代码，由于我这边返回的是支付二维码，跟实际支付无直接关联，就正常调用就行。

梳理业务流程

各接口的比例已经出来了，那么为什么要梳理业务流程呢？因为容量场景需要模拟线上业务场景。

 而我们的主要业务流程就是：登录>查询商品列表>查询商品详情>选择商品下单>提交订单支付。

然后把各业务对应的请求列出来（做基准测试时就应该理出来），比如下单就包括两个接口，部分如下表

这里就需要考虑业务脚本设计方式了，包括两种：一是直接按照接口比例设计脚本；二是按照业务比例设计脚本。

第一种接口比例：

　　合并同比例接口作为一个事务，这样可能需要额外造测试数据。比如A接口与B接口的比例一致，可以放在一个事务中。如下图所示（相同比例分类）：

　　

第二种业务比例：

　　合并同业务流程的接口，这样不用额外造测试数据，但需要计算各接口在各业务中所占比例。比如A接口比例为30%，可能在业务1占15%，在业务2占15%，就分成了两个事务。如下表所示：

　　

由于当前场景主业务单一，按照业务逻辑设计脚本，基本不用额外造测试数据，所以选择了较为简单的接口比例设计脚本。

于是把业务比例加入业务请求表中，得到了8个事务及其比例：

这是就得到了业务模型。

场景脚本实现

业务模型有了，现在我们来实现场景脚本，分为两部分。

实现业务脚本

业务脚本是个接口的比例，把基准测试的脚本拿过来改下即可，这里需要注意业务逻辑，做好业务上下文依赖数据的关联。

这些数据都是要提前准备的

实现业务比例

根据业务模型可以看出各事务的比例，我使用Jmeter的吞吐量控制器，还需要再计算一下（加入了TPS比例）：

最后Jmeter场景脚本设计如下：

 仔细看看貌似漏了那个39%的事务，由于这个接口是定时轮询支付结果接口，所以我把它放入了循环里面，包含了微信与支付宝下单。

总的TPS是3.1%，随机选择微信和支付宝支付，（23*1/2+2*1/2)*3.1%=38.75%，约等于39%，最后运行场景，结果如下：

 验证下比例（1926+20316）/94012=0.2365，与25%相差不大，得出场景正确。