Size: a a a

QA — Load & Performance

2020 November 03

ВС

Вячеслав Смирнов... in QA — Load & Performance
Viktor Ganeles
Кстати, эта штука тоже у меня не сработала.
Что именно? У меня не работает только установка Cookies для конкретной страницы, а для "/", как в примере работает.
источник

VG

Viktor Ganeles in QA — Load & Performance
Оу
источник

VG

Viktor Ganeles in QA — Load & Performance
Я просто не знал, что «/» означает что кука для корня сайта
Думал для любого семплера сработает
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Может оно так и должно работать
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Но работает только так, как написано. Лучше лишние фильтры не ставить
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
И именно так этот код работает, а какой-то другой код (а ты изменил, видимо, его) уже может не работать
источник

VG

Viktor Ganeles in QA — Load & Performance
Вячеслав Смирнов
Но работает только так, как написано. Лучше лишние фильтры не ставить
я не понял, что это фильтры. Теперь работает, спасибо..
источник
2020 November 04

S

Slip in QA — Load & Performance
gat0r
Там есть match, если нужный респонз можно поймать по признакам
Спасибо. Помогло.
источник

S

Slip in QA — Load & Performance
Всем привет. Снова вопрос по gatling'у. Есть необходимость нагружать сервер по вебсокету. При авторизации, по ресту, я получаю сессию и куку, с которыми потом конекчусь к вебсокету. Но есть момент. Нужно периодически отправлять рест запрос с этими же данными(кука и сессия) для продления жизни сессии.
Собственно вопрос. Как можно организовать периодическую отправку такого запроса в течение всего сценария?
источник

g

gat0r in QA — Load & Performance
Параллельно запустить сценарий с этим запросом?
источник

S

Slip in QA — Load & Performance
Да. Можно и так. Я нашел вот такой вариант, но он не работает.
источник

S

Slip in QA — Load & Performance
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
https://t.me/qa_load/18401
Вот тут и ещё пару раз обсуждали подобное.

Я использую два Scenario в одном Simulation. Они общаются через общий объект,
var ... Удобны коллекции LinkedBlockingQueue
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Если не получится разобраться, то завтра постараюсь помочь кодом
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Или можно использовать один сценарий, но с условием, что также есть буфер токенов, если длина очереди токенов меньше 1000 то выполняется аутентификация с добавлением токена, а если больше, то просто выполняется код, который эти токены использует. Так тоже красиво

Ньансы тут в том, что ещё активные токены сразу возвращаются в очередь, а просроченные не возвращаются. Так получается саморегуляция.

Кто-то наполняет очередь. Кто-то её использует
источник

S

Slip in QA — Load & Performance
Вячеслав Смирнов
Или можно использовать один сценарий, но с условием, что также есть буфер токенов, если длина очереди токенов меньше 1000 то выполняется аутентификация с добавлением токена, а если больше, то просто выполняется код, который эти токены использует. Так тоже красиво

Ньансы тут в том, что ещё активные токены сразу возвращаются в очередь, а просроченные не возвращаются. Так получается саморегуляция.

Кто-то наполняет очередь. Кто-то её использует
Токенов нет.  Нужно просто отправлять keepalive запрос, чтобы сессия на сервере не заэкспайрилась.
источник

VK

Vitaliy Kudryashov in QA — Load & Performance
а если просто пулинг?
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Slip
Токенов нет.  Нужно просто отправлять keepalive запрос, чтобы сессия на сервере не заэкспайрилась.
Тогда сделайте параллельный Scenario и запускайте их вместе. Так сможете контролировать профиль нагрузки.

Другой вариант - если у основного сценария есть известная длительность, шаг, путь 50 секунд. И известно, что keepAlive-запрос достаточно отправлять каждые 200 секунд, то удобно добавить в сессию переменную - количество выполненных итераций, и если номер итерации кратен 4-м и больше 0 (4, 8, ...), то заходить в if-ветку и отправлять keepAlive
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Привет всем!
Есть ли среди присутствующих те, кто пойдет на мастер-класс Стартуем в тестировании производительности на HeisenBug?
Если да, то получилось ли у вас настроить работу с Docker? Нужна ли помощь?

Инструкция по подготовке к первому воркшопу
источник

S

Slip in QA — Load & Performance
Вячеслав Смирнов
Тогда сделайте параллельный Scenario и запускайте их вместе. Так сможете контролировать профиль нагрузки.

Другой вариант - если у основного сценария есть известная длительность, шаг, путь 50 секунд. И известно, что keepAlive-запрос достаточно отправлять каждые 200 секунд, то удобно добавить в сессию переменную - количество выполненных итераций, и если номер итерации кратен 4-м и больше 0 (4, 8, ...), то заходить в if-ветку и отправлять keepAlive
Я пробовал. Проблема в том, что не получается прокинуть через сессию куку и сессию. Они становятся доступны только после авторизационного запроса.
И если в сессию еще можно передать в .queryParam("sid", x=>sessionId),где  sessionId это переменная, которой я присваиваю значение после авторизационного запроса, то куку таким образом я прокинуть не могу.
источник