KY
Это пример итоговой нагрузки N юзеров
Size: a a a
2021 October 02
KY
Внутри бегают сессии и айдишники
I
А в jmeter это как реализуется? Через что
I
Каждый шаг своя тредгруппа? В jmeter
KY
Throughput controller + loop
I
Понятно
Тут, наверное, каждый шаг - это свой сценарий + redis
Тут, наверное, каждый шаг - это свой сценарий + redis
KY
Скорее всего наложение сценариев с повторами внутри
KY
Чтобы без редиса
I
Кстати редис очень хорош для сессий, можно делать таймер к каждому ключу когда он удалиться должен
KY
Увы редис на больших нагрузках очень плохо работает
KY
Он однопоточный
KY
Ну и ресурсы под него разворачивать для таких простых вещей кощунство)
I
Это интересно - подумать
Как такое вообще реализовать, чтобы без особых костылей
Как такое вообще реализовать, чтобы без особых костылей
I
Самое забавное что тулза написана на go, а там для такого прям специально каналы сделаны
I
Но скрипты на js
KY
Ну это типичная проблема. Инструменты пилятся под то чтобы реализация нагрузки была через подход есть сценарий юзера - делаем тыщу юзеров - получаем нагрузку.
А когда у тебя подход сразу: "вижу действия тыщи пользователей" то начинается боль
А когда у тебя подход сразу: "вижу действия тыщи пользователей" то начинается боль
I
А какие данные при этом шарятся между шагами, типа - id товара, id сессии.
Интересно логику понять как и что они шарят.
Интересно логику понять как и что они шарят.
I
Аа я понял, кажется!
Если соотношение
10 аворизация
15 взять
5 купить
10 проверка
То мы просто принимаем это за 1
Запускаем как сценарий из 4х шагов
Но в каждом шаге делаем параллел контроллер, который работает в k6 реально как параллел, запуская прям одновременно, как я понял
Тогда и проблема с шэрингом решается
А количество параллельно запускаемых запросов параметризуется
Если соотношение
10 аворизация
15 взять
5 купить
10 проверка
То мы просто принимаем это за 1
Запускаем как сценарий из 4х шагов
Но в каждом шаге делаем параллел контроллер, который работает в k6 реально как параллел, запуская прям одновременно, как я понял
Тогда и проблема с шэрингом решается
А количество параллельно запускаемых запросов параметризуется
I
Сейчас ещё скину пару ссылок про это
I
То есть регулируем нагрузку вузерами и количеством параллельных запусков каждого шага