奇怪的constantUsersPerSecond二次注入行为:产生的负载突然翻倍

时间:2018-10-29 10:36:14

标签: gatling

我们正在使用gatling v2.3.0来运行内部应用程序的稳定性模拟。我们尚未测试过升级到v2.3.1的情况,但是据我所知,发行说明中没有任何变化似乎触及到了注入器,因此我很难想象在这种情况下为什么这样做会有所改变。 (我们正在准备升级到v3.0,但是仍然有一段时间我们才有机会这么做)

不幸的是,由于项目限制,我无法提供确切的方案/系统详细信息,但是方案本身是一个由40个exec元素组成的较长链,其中一组重复了50次。所有单个请求都是对其他普通REST-API的普通GET / POST / DELETE / PUT请求。这是一个相对较长的链,但是在50倍登录重复循环之外,没有什么特别的。

一些简单的场景伪代码:

  val HappyDayScenario: ScenarioBuilder = scenario("Happy Day")
    .feed(csv("userIDs").random)
    .group("create user")(
      exec(
        sequence,
        of,
        requests,
        to,
        create,
        user
      )
    ).exitHereIfFailed
    .group("a bunch of logins")(
      repeat(50){
        exitBlockOnFail(
          exec(
            sequence,
            of,
            requests,
            to,
            perform,
            login
          )
        )
      }
    )
    .group("delete the user")(
      exitBlockOnFail(
        exec(
          sequence,
          of,
          requests,
          to,
          delete,
          user
        )
      )
    )

我们正在使用以下注入配置文件:

setUp(
  new Scenario().HappyDayScenario.inject(
    rampUsersPerSec(0) to (0.6) during (10 minutes),
    constantUsersPerSec(0.6) during (72 hours)
  )
)

此处的目标是在缓慢的预热下运行初始上升至目标负载,然后在72小时内运行此静态负载量,以测量目标系统随时间的稳定性。这在几次迭代中都可以正常工作,但是最近,当我们在一个特定的系统上运行该模拟时,它的表现非常奇怪,其中constantUsersPerSec(targetLoad) during (duration hours)产生的负载似乎突然突然翻了翻,无缘无故。现在,我们已经能够重现此行为三遍。

很容易得出结论,目标应用程序中必须存在某种错误-但据我所了解的constantUsersPerSec注入器,在任何情况下,此功能应始终按其说的做可以:每秒注入一定数量的用户。

我们认为喷油器必须具有某些怪异行为的原因主要是基于以下观察结果:我们在加特林控制台输出日志中等待/完成方案的计数器变化非常明显-以前一直在变化以预期的恒定,稳定的速度。这总是在72小时周期结束时发生,在这里等待/完成曲线明显改变,如下面的简单图所示:

Scenario injection rates parsed from gatling-out log

类似的行为在加特林报告和硬件指标中当然很明显-一切都表明加特林测试运行器产生的负载突然增加。据我们所见,在测试中的应用程序中没有发生任何错误,稳定性测试大约以系统总容量的50%运行,因此即使以两倍的速度运行也能正常工作。

我们当然要进行两次和三次检查,以确保仿真实际上是在上述注入配置文件下运行的,并且targetLoad值的配置值是静态的,并且不会改变(尽管我不认为可以首先是动态的。

我们无法解释造成这种情况的原因,因此,在考虑进行所有升级步骤之前,或者在可能的情况下,创建一个有问题的github问题之前,我们将在此处针对情况进行第二组分析。也许有些明显的东西我们不见了。

这是constantUsersPerSec功能本身的一个可能的错误/问题,还是任何人都可以确定此行为的可能原因-是由于误解还是使用不正确?

0 个答案:

没有答案