Спасибо!)

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

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

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

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

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

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

Ссылка на вчерашнее выступление Анатолия https://youtu.be/4M55s_YqKc4?t=3720

Можно сделать финт ушами, если для измерения времени обработки со стороны сервиса нужно городить велосипеды - пусть он сам говорит сколько времени потратил. Можно сходить в разработку и попросить их добавить фичу, чтобы сервис в хедерах отдавал сразу время обработки на своей стороне или таймстемп начала и окончания. Далее в jmeter это парсить и подсталять вместо latency в samplerresult.

вроде на https://prometheus.io/ похоже?

Это уже уровень непосредственно мониторинга системы. Если у вас что-то есть подобное - прометей, заббикс и тп - как раз туда можно пушить данные по времени обработки вызова и потом смотреть их в той же Grafana, к примеру
Из коробки системы мониторинга обычно не умеют собирать такие специфичные метрики- поэтому со стороны разработки это должно быть реализовано.

Ну так нагрузка без мониторинга пули на ветер, не?)

Ну так да, тут надо участие разработки, Сережа прав

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

жметр при этом делает 2к рпс

а можно чуть больше контекста?

стреляю в один и тот же сервис, все рекомендации по жметру сделал (non-gui mode, листенеры отключены итд) т.е тест совсем примиитвный, даже слегка тюнил OS, типа ulimit. И при всем при этом низкий рпс

как сконфигурированна threadgroup по потокам? и какую treadgroup используешь?

ultimate thread group, треды выдаю сразу фиксировано, пробовал от 100 до 1000 ничего не меняется

время параметризировано, тоже разное выставлял

Размер пула потоков задается как

RPS * <max response time> / 1000

, но c шейпинг-таймером не всё так просто, при увеличении входящей интенсивности будет расти время ответа, а соответственно максимальное время ответа, т.е. на таком профиле в любом случае  нагрузка не будет подаваться линейно, а будет выходить на некоторое подобие насыщения.
Я бы рекомендовал для начала убрать шейпинг-таймер и линейно увеличивать потоки, чтобы определить при скольки потоках достигается максимальная производительность сервиса, а уже зная это количество настраивать шейпинг таймер.

RPS * <max response time> / 1000

время ответа почти нулевое, машины в одной сети, но я попробую, спасибо

Просто если на 1000 потоках не будет достугнута интенсивность в 40к rps, то шейпинг не будет работать так, как хотелось-бы)