Как вызвать несколько API параллельно для нагрузочного тестирования (с помощью Gatling)? - PullRequest
0 голосов
/ 23 мая 2019

В настоящее время я пытаюсь загрузить свои API-интерфейсы с помощью Gatling, но у меня есть очень специфический тест, который я хочу выполнить.Я хотел бы смоделировать виртуального пользователя, вызывающего все мои API (16 из них) одновременно.Я хотел бы повторить это несколько раз, чтобы иметь представление о среднем времени, которое требуется для того, чтобы мои API отвечали, когда все они вызывались одновременно.

Метод, который я использовал, был:

  • Создание сценария для каждого APIв секунду и удерживая его в течение 60 секунд.

Цель состояла в том, чтобы получить 60 итераций того, что я хотел.

К вашему сведению, я использую Gatling 3.1.2

//This is what all my scenarios look like

val bookmarkScn = scenario("Bookmarks").exec(http("Listing bookmarks")
                .get("/bookmarks")
                .check(status.is(200))
            )

//My setUp

setUp(
    bookmarkScn.inject(
        atOnceUsers(60)
    ).throttle(
        jumpToRps(1),
        holdFor(60)
    ),
    permissionScn.inject(
        atOnceUsers(60)
    ).throttle(
        jumpToRps(1),
        holdFor(60)
    ),

//Adding all the scenarios one after the other

).protocols(httpConfig)


Я получил некоторые результаты с помощью этого метода, но они не совсем то, что я ожидал, и если я продолжу тестирование слишком долго, в конечном счете, каждый вызов просто прекратится.

Предполагалось, что он займет больше времени.время, чем обычно (например, от 100 мс на API до 300 мс).

Мой вопрос: правильный ли этот метод?Можете ли вы помочь мне достичь моей цели?

1 Ответ

0 голосов
/ 29 мая 2019

То, что у вас есть, должно работать, но, вероятно, есть более простой способ указать эту инъекцию. Вместо

bookmarkScn.inject(
    atOnceUsers(60)
).throttle(
    jumpToRps(1),
    holdFor(60)
),

вы можете использовать

bookmarkScn.inject(
    constantUsersPerSec(1) during (60 seconds)
),

с точки зрения ваших результатов, я ожидал бы, что проблема лежит где-то внизу процесса сбора данных - 16 одновременных пользователей, делающих простые запросы GET, очень просты для Gatling. В других местах могут возникнуть проблемы с производительностью вашего приложения или промежуточной инфраструктуры.

...