业务模型
在容量场景中,每个业务比例都要符合真实业务场景的比例。如果不符合,那场景的执行结果也就没有意义了。
做场景时首先要明白,当前的场景是要模拟历史业务场景,还是未来业务场景。
如果是未来的业务场景,那就要靠业务团队给出评估,而非性能团队。
如果一个系统有历史业务数据,那我们获得业务模型就有背景数据了
抽取生产业务日志是为了得到对应的业务比例
大体上来说,抽取真实业务模型有两个大步骤:
1. 抽取生产业务日志。
<1>. 当没有日志统计系统时,使用 awk 命令来抽取;
【哪段时间里的访问量最高】
~]# cat 20201026141300.nginx.log|awk '{print $4}' |uniq -c
请求 URL 来做统计
~]# cat 20201026141300.nginx.log|awk '{print $7}' |cut -c 1-50|uniq -c
<2>. 使用 ELFK 来抽取。
可以分为两个阶段
1. 第一个阶段是统计大时间段的日志信息,然后逐渐缩小范围,比如说按年、月、天、时、分的顺序。
一步是为了将系统的峰值请求覆盖住。
2. 第二个阶段是细化所选择的时间段,得到按秒来统计的结果 xx TPS
然后把生产的业务场景和测试中的场景进行对比。
具体有以下几个步骤:
1. 安装 ELFK。这里的 ELFK 是指 ElasticSearch/Logstash/FileBeat/Kibana 的组合。
2. 配置好 ELFK 后,在 Kibana 的 Discover 界面就能看到收集的信息。
注意,一条日志对应的就是一次命中。
3. 通过选择时间段就可以看到有多少请求在这个时间段内。
4. 要想得到接口请求的百分比,可以点击“Dashboard”中的“可视化”,创建一个 Lens 可视化面板,选择相应的 URL 字段就可以看到各个接口的百分比了。
注意:如果出现某个请求的高并发时间点和其他的请求不在同一时间点,就一定要做多个场景来模拟,因为场景中的业务模型会发生变化。
得到总 TPS 之后,我们要根据测试目标,分三种方式处理这个总 TPS,而这三种方式都是以业务目标为前提的。
1. 业务无变化,应用版本有小变化(通常只是小的功能变化或修改 Bug):在这种情况下,我们只要将计算出来的 TPS 做为性能场景总的 TPS 指标即可。
2. 业务无变化,应用版本有大变化(比如说架构变更):在这种情况下,我们只要将计算出来的 TPS 做为性能场景总的 TPS 指标即可。
3. 业务有变化,应用版本有大变化:在这种情况下,我们要根据业务估算的增量来做相应的 TPS 增量计算。如果根据业务变化趋势预估会增加 20%,那你就可以在上面计算的总 TPS 的基础上,再加上对应的 20% 即可。
2. 梳理业务逻辑。
完成全部流程的比例:比如登录接口 12%,下单接口7%,完成全部流程比例 7% / 12% =58%
整体流程说明
统计生产业务量【年月日时分秒】--》业务场景-峰值TPS--》细分TPS--》各接口比例--》梳理业务流程--》实现业务脚本--》在压力工具中实现业务比例。
在业务模型抽取时我们要注意几个关键点:
1; 抽取时间:抽取时间一定要能覆盖生产系统的峰值时间点;
2; 抽取范围:抽取的范围要足够大,因为在一些场景中,即便不是峰值,但由于某个业务量较大,也会出现资源消耗大的情况;
3. 业务比例在场景中的实现:得到业务模型之后,我们在性能场景中一定要配置出对应的业务比例,不能有大的偏差。