а графана там не объявляла еще списокчек как они классно всё сейчас возьмут и в к6 сделают?)

Привет, подскажите пожалуйста, а как вы шарите куки между thread groups в Jmeter. Через beanshell скрипт и куки менеджер?

забудь слово beanshell

можно через redis или props

Зачем куки шарить?
И как именно надо зашарить от одного потока к другому?
Типа один поток всем раздает?

Например в сетапе залогинился и загрузил страницу, а в других дергаешь урлы

через пропсы

Ага, особенно если все под одной кукой
Или можно на каждый поток свой property

Once only Controller с аутентификацией, медленный разгон, убрать галочку Clear on each iteration в Cookie Manager

После разгона у всех будут куки

Но если в куках jwt токен с временем жизни 10 минут, то такой способ не подойдёт

Пробовал при таком подходе в одном потоке делать логины раз в 5 минут, а во всех остальных получать ку-ку из property - можно, но надо добавить тогда Concurrent Controller, иначе происходит момент, что один потолок ку-ку уже удалил, чтобы обновить, а куча потоков ее хотели получить, а ее не было в property

Точнее так. Когда поток логина имея в куках jwt токен 1 запрашивает новый, то сервер старый токен 1 делает устаревшим, и выдает потоку новый токен 2. В этот момент все потоки получают 401, пока они не получат новый токен из property

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

ага

А если тест просто для замеров? не хотелось бы там ошибки

Да, я для замеров использую. Бывает например вопрос, а во сколько раз даст ускорение добавление вот этого индекса.
Можно посчитать во сколько раз ускорится SQL-запрос, а вот для HTTP-метода надо написать бенчмарк на метод.
В таком случае, небольшое количество ошибок 401 не влияет на точность измерения

Спасибо

Для полноценного интеграциононго теста. Лучше использовать очередь токенов в property.
Или даже Redis
Чтобы ошибок не было никаких

@rukkola30 не забыл?

Помню
Просто пятница, до дома ещё дожить надо

Понял) ок

Более сложная работа с токенами.

Например, мы знаем что jwt токен выдается на 600 сек. А шаг нагрузки транзакции 200 сек.
Значит, каждый токен можно будет использовать, если на момент начала его использования у него останется еще 200 сек жизни.

Простой формат синхронизации потоков по работе с токенами такой.
В JSR 223 при получении токена переменную со значением

def stop = System.currentTimeMillis() + 600_000 - 200_000;

Положить в очередь структур

def tokenMap = [:]
tokenMap["stopTime"] = stop
tokenMap["token"] = jwtToken
tokenMap["username"] = userName
props.get("tokenQueue").put(tokenMap)

А потом в другом JSR-223 при получении токена с целью использования, можно делать вот так

def tokenMap = props.get("tokenQueue").take()
while(tokenMap["stopTime"] > System.currentTimeMillis()) {
    tokenMap = props.get("tokenQueue").take()
}
props.get("tokenQueue").put(tokenMap);
vars.put("token", tokenMap["token"])
vars.put("username", tokenMap["username"])

tokenQueue в данном случае - https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/LinkedBlockingQueue.html

Фигачь в кафку сообщения, содержащие в теле таймштамп

Потом вычитывай из базы все новые  строки, и как только вычитал - считай разницу между таймштампом в теле и таймштампом «сейчас»