Проблема не в том, как время считать, а как эту разницу отобразить в отчете по нагрузке. Плюс к этому формат сообщения в кафку строго определён и он не включает в себя никакой timestamp
То есть грубо говоря, если бы я эту разницу загонял в локальную пересенную через .put (к примеру в ${timestamp}, нужно ее где-то в финальном отчете отобразить
Может сумбурно объясняю, но надеюсь суть понятна

uuid+start+finish
дифаешь и показываешь, в чем вопрос то?)

Ну в инфлакс шлешь первый таймстамп в качестве timestamp и время обработки в качетсве field
Получаешь в графане график
По временам обработки

Это пример который я для себя для экспериментов делал
всё просто
сам только начал изучать

group - это как транзакция в jmeter
можно их вкладывать одну в другую

имя запроса - это tags name

sleep() - это pacing

scenarios - это профили, они запускаются все сразу, но можно запускать часть из них, можно параметризировать, как я понимаю
Так что тут удобнее всё гораздо

exec в scenarios - это то что будет исполняться с заданной интенсивностью
у меня case1 и case2

в примере там 20 сек нагрузка идет одна и та же, для эксперимента
100 100 100
50 50 50

но можно задать например

      
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '3600s', target: 100 },
        { duration: '3600s', target: 100 },
        { duration: '3600s', target: 200 },
        { duration: '3600s', target: 200 },
        { duration: '3600s', target: 300 },
        { duration: '3600s', target: 300 },
      ]

чтобы ступени и подъемы были
уверен можно и красивее, но пока так сойдет для эксперимента

Файл заменил, сначала не тот приложил
вот этот -  который хотел

Понял, немного геморрой но вроде понимаемой. Спасибо!
А можно перекинуть переменную из сценария 1 в сценарий 2? Например

Вопрос, наверное, больше про js.
Думаю можно, как не знаю.

Вот ещё в минусы, кстати

k6 doesn't have a native distributed load testing mode. You can containerize it yourself and deploy it via Kubernetes, for instance, but it does require a more involved setup. The team is also working on the k6 Operator, which makes setup significantly easier, but it is experimental and comes with drawbacks such as not supporting threshold synchronization between instances. For now, the easiest way to scale up on k6 is by using the paid service k6 Cloud, which reduces setup time and complexity significantly.

Нет поддержки распределенных запусков

Она имплементится и в целом есть даже статья как его настраивать.

Тут, как я понял вылезает другая проблема
Невозможно шарить переменные между потоками, которые при это на разных инстансах находятся

Да. Правда имхо и не стоит так делать. Пока мне для такого шарить данные между скриптами не было необходимости

Имеется ввиду между потоками?

Это мне и не надо на сомом деле

Меня больше волнует что там нет нативной поддержки разнорпсного сценария

Я не понимаю что это значит

Можешь пример привести?

Типо авторизация 10 рпс
Потом поиск товара 15 рпс - ID взять
Потом 5 рпс купить товар с тем id - id корзины взять
Потом 10 рпс проверка корзины с ее id