если у тебя хттп, то там будет всегда реквест-респонс и ответ будет дожидаться до таймаута (60 сек по умолчанию)

Глазами диаграмму анализировать?

Это я знаю

у тебя стата будет по твоим запросам

на лету в графане видно будет за 20 сек дошло или не за 20

МьІ использовали как-то ELK stack правда с Jmeter. ОбьІчньІй csv listener над которьІм висит FileBeat и посьІлает результатьІ в Logstash + elastic. Logstash еще grok'ом парсить каждьІй результат и сетить поля для записи в elastick (имя реквеста, timestamp, имя user flow, response code and etc). Все работает в real-time, с коробки обратная связь между filebat и logstash, encryption, scaling Logstash (говорят правда геморно) + даже если отвалиться connection, то потом можна переслать.
МинусьІ
1. Тормознутость elasticsearch если смотреть данньІе на большом промежутке времени, но для тестов вполне норм.
2. Не хватает некоторьІх вещей в grafana плагине для elasticsearch.

Для Gatling можна так же подойти - натравить filebeat на файл с результатами

20 сек? что у вас за запросы такие О_О

пользователь выспатся успеет пока дождется ответа 🙂

не знаю)) это не у нас

а 🙂 это ради примера было? :))

это у ранорекса на соапе

вьетнамские флешбеки на каждыйдень

А вот здесь поподробнее... Не попадут ли такие запросы сразу в Failed?

спасибо, тоже думал об этом
тогда можно вообще лог парсить на лету поднятым сервисом

а почему они должны попасть?

если у тебя таймаут 60 сек, а приходит всё за 20 то всё ок

если ты выставишь ассерт по нижней границе (типа от 20 сек и выше) то ассерт просто покажет что такие запросы были и результат теста будет зафейленным, но запрсоы всё равно проходить будут

А стоп, нужно анализировать response time distribution

Но у нас нагрузки бьІли маленькие, до 50 rps и хватало 1 logstash + 1 elasticsearch без никаких оптимизаций ( только heap для elasticsearch подняли до 4 GB)