Странное поведение ConstantSsersPerSecond: внезапное удвоение нагрузки

Question

Мы используем gatling v2.3.0 для запуска моделирования стабильности внутреннего приложения. Мы еще не тестировали обновление до v2.3.1, но, насколько я вижу, в примечаниях к выпуску изменений, которые, похоже, касаются инжекторов, нет, поэтому мне сложно представить, почему это что-то изменит в этой ситуации. (Мы готовим обновление до v3.0, но у нас будет время, прежде чем мы сможем это сделать)

К сожалению, я не могу предоставить точные детали сценария / системы из-за ограничений проекта, но сам сценарий представляет собой довольно длинную цепочку из ~ 40 элементов exec, набор которых повторяется 50 раз. Все индивидуальные запросы - это просто запросы GET / POST / DELETE / PUT к обычному REST-API. Это относительно длинная цепочка, но за пределами цикла повторения входа в систему 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, эта функция всегда, при любых обстоятельствах, должна делать именно то, что говорит на банке: вводить определенное количество пользователей каждую секунду.

Причина, по которой мы считаем, что должно быть какое-то странное поведение с инжектором, главным образом основана на наблюдении, что мы, счетчики для сценариев ожидания / выполнения в журнале консоли gatling, очень отчетливо изменяют темп - там, где он ранее изменялся в постоянном, устойчивом темпе, как и ожидалось. Это всегда происходит ближе к концу 72-часового периода, когда кривые ожидания / выполнения четко меняются, как показано на простом графике ниже:

Подобное поведение, конечно же, очевидно в отчете gatling и метриках аппаратного обеспечения - все указывает на внезапное увеличение нагрузки, генерируемой тестером gatling. Насколько мы видим, в тестируемом приложении ошибок не возникает, тесты стабильности выполнялись примерно на 50% от общей емкости систем, поэтому даже при удвоенной скорости он работает правильно.

Мы, конечно, дважды и трижды проверили, что симуляция действительно выполняется с вышеупомянутыми профилями впрыска, и что значения config для значений targetLoad являются статическими и не изменяются (хотя я не думаю, что это может быть динамический в первую очередь).

Нам не удалось объяснить, что является причиной этого, поэтому мы обращаемся здесь за вторым взглядом на ситуацию, прежде чем мы рассмотрим прохождение всех этапов обновления или, возможно, создание проблемы gitub в этой ситуации. Может быть, есть что-то очевидное, чего нам не хватает.

Это возможная ошибка / проблема с самой функцией constantUsersPerSec, или кто-то может определить вероятную причину такого поведения - будь то по недоразумению или неправильному использованию?