【安全测试】性能测试进阶(Part5-并发测试的方法3)

上两篇文章中,我们介绍了并发测试的方法1和方法2:

【安全测试】性能测试进阶(Part3-并发测试的方法1)

【安全测试】性能测试进阶(Part4-并发测试的方法2)

这篇文章我们介绍并发测试方法3:用并发的方式来测试并发,只建立不拆除——测试至始至终都不拆除

相关阅读:

【安全测试】性能测试进阶(Part1-基本概念)

【安全测试】性能测试进阶(Part2-新建测试的方法)

首先我们来回顾一下并发测试的四种方法

并发测试的方法

并发有4种测试方法。主要的差异点就是在并发测试的时候,是否会有连接的拆除。简单总结如下:

方法3:用并发的方式来测试并发,从一开始就边建边拆

测试场景(可以把新建和并发关联起来测试,找到两者的平衡点)

场景1:想知道,某现网环境,平均50w并发,3000新建,设备是否可以支持。

场景2:想知道在xxx的并发下,新建最大可以达到多少。

测试思路

  • 先测试最大新建。
  • 然后以最大新建的1/10来估计整体的爬坡时间(1/10是经验值,整体爬坡时间=期望的并发值/新建值)
  • 然后考虑在爬坡过程中,希望拆除和新建几次。(如果以1/10来估计,那希望拆除和新建的次数不能超过10次,如果是以1/8来估计,就不能超过8次,依次类推)
  • 假设我希望的拆除和新建的次数是4次。那就设置think time为爬坡时间,除以4。

测试用例5:测试在并发100w情况下,系统最大的新建能够达到多少

还是以上面的100w并发为例(AMD平台)。

假设AMD平台测试的新建是3w。以最大新建的1/10来设置当前的新建,及新建为3000.
此时的爬坡时间为:100w/3000= 334s

假设我希望在这个测试模型中,在爬坡阶段,可以有4次连接的建立和拆除。
设置think time = 334 /4 =84s

Load配置:

结果分析:

测试时,在tcp新建为9000左右,出现了失败,对应的并发为70w左右。
———这也是在测试并发的时候,有时候并发会打不上去的原因。

根据结果进行调整,进行第二轮测试

调整方式第一步:首先考虑增加think time的时间。

这可以通过减少在爬坡阶段拆除和新建的次数来达到。在这个例子中,可以将拆除和新建的次数先减少为3次(从4改为3)

对应的,将think time改为 334/3 = 112s

再次运行,发现还是出现大量失败:

通过实时统计来分析结果:

发现在新建9000的时候,维持一段时间,大概在并发90w左右,还是出现大量的失败,这说明在新建9000下的并发90w几乎达到了系统最大的处理能力。

对HTTP transactions这个图,找靠近失败附近,但是可以成功的新建值,发现是8500左右。

由于90w离100w并发还有一定的负载压力,所以我们可以考虑取 7000~8000的新建,作为在爬坡阶段,可以达到的最大的新建值。

这里,我们用7000新建来试试看。

假设还是希望在爬坡中可以拆除和新建4次,那此时的新建速率就是1750。
爬坡时间就变成了 100w/1750 = 572s
Think time = 572/4 = 142s

修改后的load和action列表如下:

再次运行,发现还是会出现少量失败:

 

按照上述方法再重复进行测试。新建速率为 6000/4=1500
爬坡时间为 100w/1500 = 667
Think time = 667/4 = 167测试成功,如下图所示:

这说明在并发100w的情况下,新建最多为每秒6000 connections。

扩展说明

在上述并发100w的情况下,新建最多为每秒6000 connections。

此时虽然客户端没有unsuccessful(说明都收到了200 ok)

但此时服务器端已经出现了大量失败(closed with error)。

从业务的层面,可以认为测试成功(可以理解为200ok,即为数据传输成功)

但是从传输层面,依然是不成功的。

这时,think time和latency的差别就会显现出来——所有配置条件不变,把think time改为latency,应该就会出现比较大的失败。

方法4:用并发的方式来测试并发,只建立不拆除

测试场景:测试最好值

方法过于简单,和实际场景的差异也比较大,本文不介绍。

发表评论