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

А как тогда лучше решить проблему : создать например на 100 потоков 100 юзеров? А  что делать с 500 и выше потоков?

Я создаю пользователей интеграционными тестами, потом CSV с токенами подсовываю жметру

Токен дается при создании логина?

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

я интеграционными тестами из эластика подтверждения беру

А можно пример с эластиком?

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

В дополнение к варианту через эластик.  Используйте гугловые алиасы. my_load_user+{counter}@gmail.com
Я так создавал интеграционными тестами. Главное чтобы ваша система позволяла логиниться по email, который содержит "+".
Но это крайний случай, когда ничего другого быстро сделать не могут.

Алиасы есть в RFC, если не позволяет - плохо.

Привет! Спасибо за доклад, очень крутой! У меня есть вопрос, буду очень признателен, если поможете с ним)

Есть приложение, которое на вход для обработки получает файлы до 50мб. Нужно уметь обрабатывать большое кол-во таких файлов, к примеру, до 100 запросов в секунду.
Общение с приложением происходит посредством POST запросов.
Хочется проверить это приложение под нагрузкой, но упираюсь в банальную пропускную способность сети. И пока не придумал как это решить. В итоге инструментом нагрузки (jmeter) могу получить только полное время работы (отправка запроса + время работы приложения + получение ответа). И не смог в инструменте вычленить метрики отдельно по работе приложения (время от окончания отправки запроса и до начала получения ответа).

Для решения проблемы пробовал два подхода:

1. Логировать начало и конец обработки каждого из запросов. Но при таком подходе увеличивается работа при записи логов и ожидаемо приложение работает медленнее.
2. На том же сервере развернуть Эхо-сервис, который отдаёт ответ нужной величины. Потом вычесть из времени работы основного приложения время общения с Эхо-сервисом (т.е. по факту вычесть время на перегон файлов по сети). Но как-то не понятно как доверять таким метрикам и будут ли они правдивы.

Может у вас были подобные задачи или проблемы и как вы их решали?