круто

но я не совсем понял, тут ты в примере накидал одинаковы старт стопы

и типа считаешь их в рандомном месте а потом вставляешь

когда релизить будешь?

Хотя вроде догнал

Да, это просто пример. Что поля событий можно заполнить, чем угодно. Строками, датами, числами, из Expression или просто значениями, разнотипными.

Думаю найду время когда зарелизить. Под этим понимаю, сделать так, что плагин в maven central попал. Сам по себе он работет уже. Хотя планов тут больше было.

В плане было - повторить API LoadRunner где есть функции start_transaction, end_transaction. При этом скрестить с API JMeter, где есть возможность программно создать SampleResult

Пока сделано совсем просто - создание результата со всеми заполненными полями. Удобно когда нужно залогировать какое-то промужеточное событие, которое пришло из AMQP, ещё чего-то - отразить в статистике Gatling запрос, который не отправлялся из Gatling

В Гатлинге есть подобный функционал с транзакциям

Группы называются

И есть переключалка чтобы кумулятивно респонсы считались

Да, группы Gatling знаю, и использую активно

Ради них и сначала начал переделывать Grafana Report для Gatling

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

Даже доклад про это готовил. На HeisenBug предыдущем

И для этого доклада сделал это API, плагин

Чтобы в одном потоке запрос послать. В другом получить. И залогировать время с момента отправки запроса до момента получения

Ну это правда крутое решение мне понравилось:)

Уже хочу использовать :)

Думаю мы зависимость в свой швейцарский нож затащим

А чо в репорте хотел?

Я вот щас тоже свой анализатор пишу