DS
Я бы одной тред группой слал сессии в Redis, а второй доставал бы оттуда значения
В принципе это можно реализовать через concurrent hashmap
Size: a a a
2019 November 14
A
PН
Одной группой это делать надо
PН
Паларелленость сценариев зло
MD
Логин -> получение сессии ->
-> 1) В одном цикле шлется СИНК с этой сессией каждые 4 сек
-> 2) В другом цикле ПОСТ запрос с этой же ссесией
-> 1) В одном цикле шлется СИНК с этой сессией каждые 4 сек
-> 2) В другом цикле ПОСТ запрос с этой же ссесией
А вот это твое требование на раз в 4 сек насколько жесткое? Логины вообще насколько часто происходят?
MD
Если логинов в настоящей нагрузке мало - может их вообще из основного теста убрать и делать это предварительно - или вне jmeter или startup threadgroup и писать куки или что там у тебя в файл и его уже использовать
DS
А вот это твое требование на раз в 4 сек насколько жесткое? Логины вообще насколько часто происходят?
Такая архитектура - пользователь залогинился и клиент шлёт синк постоянно , каждые 4 сек, и параллельно отправляет запросы .
DS
Если логинов в настоящей нагрузке мало - может их вообще из основного теста убрать и делать это предварительно - или вне jmeter или startup threadgroup и писать куки или что там у тебя в файл и его уже использовать
Сколько пользователей задам..Ну это разово, что б получить сессию..
MD
Сколько пользователей задам..Ну это разово, что б получить сессию..
Реальные пользователи новые как часто будут приходить? Ну или можно пойти от времени жизни типичной сессии и числа пользователей
MD
Ты хочешь растить число пользователей в одном тесте, или нормально будет сделать тесты, в которых это число зафиксировано?
DS
Ты хочешь растить число пользователей в одном тесте, или нормально будет сделать тесты, в которых это число зафиксировано?
Можно задать колличество , есть сервер авторизации , от него только сессия нужно , а дальше только сервер на который синк идёт по кругу и пост запросы сыпятся
MD
Вообще, я бы не очень заморачивался с тем, чтобы точно воспроизводить прод, главное понимать специфику нагрузки и на что влияют отступления.
Если синки это что-то типа keep-alive и они с основными запросами не взаимодействуют, я бы вообще разделил на две тредгруппы, как выше советовали, даже совсем бы развязал их по данным - вплоть до отдельных пользователей, без всяких обменов через redis
Если синки это что-то типа keep-alive и они с основными запросами не взаимодействуют, я бы вообще разделил на две тредгруппы, как выше советовали, даже совсем бы развязал их по данным - вплоть до отдельных пользователей, без всяких обменов через redis
DS
Вообще, я бы не очень заморачивался с тем, чтобы точно воспроизводить прод, главное понимать специфику нагрузки и на что влияют отступления.
Если синки это что-то типа keep-alive и они с основными запросами не взаимодействуют, я бы вообще разделил на две тредгруппы, как выше советовали, даже совсем бы развязал их по данным - вплоть до отдельных пользователей, без всяких обменов через redis
Если синки это что-то типа keep-alive и они с основными запросами не взаимодействуют, я бы вообще разделил на две тредгруппы, как выше советовали, даже совсем бы развязал их по данным - вплоть до отдельных пользователей, без всяких обменов через redis
Да-да, проверка , что живой) завтра попробую разобраться и на две группы
MD
Да-да, проверка , что живой) завтра попробую разобраться и на две группы
Важно, связаны ли эти синки с тем, как юзер делает запросы
MD
Да, у вас эти 4 сек прибиты гвоздями или произвольно заданы? Я бы сначала посмотрел, как оно живет чисто под синками, потому что нагрузка-то нормальная - 1к живых юзеров уже 250 rps
MD
а если сервер будет подтупливать в какие-то моменты и копить запросы - возможна еще и сборка таких запросов в пачки, т.е. пиковый будет заметно выше
DS
Да, у вас эти 4 сек прибиты гвоздями или произвольно заданы? Я бы сначала посмотрел, как оно живет чисто под синками, потому что нагрузка-то нормальная - 1к живых юзеров уже 250 rps
Бэк так настроен ...
MD
Так это же фронтом управляется или у вас не http а свой протокол?
MD
@exWizard кстати, идеологически про построение тест-планов советую посмотреть старый доклад Андрея Похилько https://video.yandex.ru/users/ya-events/view/2863/
