Size: a a a

QA — Load & Performance

2020 August 04

ВС

Вячеслав Смирнов... in QA — Load & Performance
Sam 7
И ещё раз привет. Сейчас столкнулся с проблемой, когда сервис отвечает достаточно быстро, но в какой то момент джиметр начинает брать новые треды из пула и упекается в лимит(нагрузка падает). При этом ошибок нет и время ответа не растёт, что странно. Кто то сталкивался с подобным поведением?
Бывает дело не в ответах сервера, а в скрипте.

В скрипте как устроено получение тестовых данных? Бывает их получают из нагружаемой же базы данных
источник

S7

Sam 7 in QA — Load & Performance
Нет. Данные только из цсв
источник

S7

Sam 7 in QA — Load & Performance
Сценарий простой - 1 запрос - 1 ответ
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Тогда все же соединения заканчиваются
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
HTTP?
источник

S7

Sam 7 in QA — Load & Performance
Https
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Добавьте в jmeter.properties:
httpclient.reset_state_on_thread_group_iteration=false

Или задайте через опции -P
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
При коротких итерациях с быстрыми ответами соединения быстро закончатся
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Там даже keep alive не включить - весь сценарий из одного запроса
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Потому есть выход, включить такой keep alive на весь тест, через указанный параметр
источник

S7

Sam 7 in QA — Load & Performance
Уже пробую
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Или сделать loop controller, на 50 итераций. И поместить запрос в него
источник

ВС

Вячеслав Смирнов... in QA — Load & Performance
Тогда можно не менять опции и сработает keep alive
источник

S7

Sam 7 in QA — Load & Performance
reset_state = false - помог, с 250 рпс подтянулся до 550, но дальше та же проблема
источник

AG

Alex Grishutin in QA — Load & Performance
Sam 7
reset_state = false - помог, с 250 рпс подтянулся до 550, но дальше та же проблема
вы из под винды тестируете или юникса?
источник

S7

Sam 7 in QA — Load & Performance
Винда
источник

AG

Alex Grishutin in QA — Load & Performance
гляньте вот это, может помочь
http://smallvoid.com/article/winnt-tcpip-max-limit.html
источник

AG

Alex Grishutin in QA — Load & Performance
Viktor Ganeles
Слазай в исходники cache manager
Никуда лазить не пришлось... завалился в проперти и поменял cache_manager.cached_resource_mode на RETURN_200_CACHE

Да, по сути реквест кешируется... Судя по логу в дебак моде, кешируется на год, a max-age на такое время лежит в куках...

В код лезть наверное надо, только для того что бы увидеть по какому принципу он выбирает max-age из всех доступных кук
источник

S7

Sam 7 in QA — Load & Performance
Спасибо, смотрю. А по юниксам что то похожее есть (на будущее)
источник

AG

Alex Grishutin in QA — Load & Performance
Sam 7
Спасибо, смотрю. А по юниксам что то похожее есть (на будущее)
источник