ВС
Думаю, стоит подготовить бенчмарки, простые и повторяемые
Size: a a a
2020 March 29
ВС
Вот с этим могу помочь
KY
Ну, как бы да. После того фикса в количество потоков оно больше не упирается.
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
Но тестировать-то как-то нужно? Ну, хочется увидеть, что «раньше мильён потоков не создавался, а сейчас вот, работает».
И получается, что раньше не работало, т.к. упиралось в треды, а сейчас всё равно не работает, т.к. упирается в память.
Вот и дилемма: это случай такой дурацкий? Или оказывается, что ни у кого нет проблем ни с памятью ни с потокамим?
фактически чаще всего вижу утечки в тестах, где есть много регулярнк на телах ответа или есть какая-то обработка не супер простая, даже большое количество ассертов иногда приводит к потере памяти, но это чаще всего сложно оценить ибо выселяем то мы например 8гб, инструмент съедает 8гб в 9 из 10 случаев, а хватило ему этого на все свои задачи или он уперся во что-то без ошибок out-of-memory - не всегда понятно, ведь работа с памятью, как я понимаю может быть ниже необходимой для теста производительности
2020 March 30
VS
И мы зная, что копирование есть, теперь стараемся не раздувать тесты, не комментировать там блоки - а сразу удалять всё лишнее и отладочное
Кстати. надо проверить копируются ли disabled элементы. Если копируются, то это легко исключить
VS
Думаю, стоит подготовить бенчмарки, простые и повторяемые
Вот, да, осмысленные бенчмарки всегда полезны.
VG
Кстати. надо проверить копируются ли disabled элементы. Если копируются, то это легко исключить
Кстати, про Jmeter и память:
я запускаю 2-3 Jmeter на нагрузочной станции и вижу, что на ней кончается память.
Открываю JVM, и вижу что каждый Jmeter вскоре после старта теста захапал по 4 гига памяти а использовал дай бог по одному.
Но ещё один Jmeter уже не запустить - памяти свободной-то нету
я запускаю 2-3 Jmeter на нагрузочной станции и вижу, что на ней кончается память.
Открываю JVM, и вижу что каждый Jmeter вскоре после старта теста захапал по 4 гига памяти а использовал дай бог по одному.
Но ещё один Jmeter уже не запустить - памяти свободной-то нету
VG
(это я в прошлом году наблюдал, jmeter 5.0 или 5.1, точно не скажу уже)
VS
Точно, это она и есть:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62861
И её значение сейчас по умолчанию True. То есть JMeter по умолчанию ведёт себя, как ускоренный. Чего раньше не было.
Значит нужна будет статья, почему иногда надо нужно замедлить JMeter. С рассказом об отключении «same user on each iteration»
https://bz.apache.org/bugzilla/show_bug.cgi?id=62861
И её значение сейчас по умолчанию True. То есть JMeter по умолчанию ведёт себя, как ускоренный. Чего раньше не было.
Значит нужна будет статья, почему иногда надо нужно замедлить JMeter. С рассказом об отключении «same user on each iteration»
Ещё вспомнилось: https://bz.apache.org/bugzilla/show_bug.cgi?id=64289
Bug 64289 - Make httpclient4.time_to_live defaults to 60000 to be closer to typical browser behavior
Тоже будет в 5.3
Bug 64289 - Make httpclient4.time_to_live defaults to 60000 to be closer to typical browser behavior
Тоже будет в 5.3
AK
Ещё вспомнилось: https://bz.apache.org/bugzilla/show_bug.cgi?id=64289
Bug 64289 - Make httpclient4.time_to_live defaults to 60000 to be closer to typical browser behavior
Тоже будет в 5.3
Bug 64289 - Make httpclient4.time_to_live defaults to 60000 to be closer to typical browser behavior
Тоже будет в 5.3
Блин, jmeter-у карантин на пользу 😅
N
Коллеги, всем привет
Столкнулся с такой проблемой:
Тестировал ftp-сервис на нагрузку, после пары падений его переконфигурировали (включили защиту от ДДОС и прочее) и теперь jmeter просто отваливается по тайм-ауту, но через консоль и другие клиенты фтп работает
Какие есть мысли или способы в таком случае делать нагрузку?
Столкнулся с такой проблемой:
Тестировал ftp-сервис на нагрузку, после пары падений его переконфигурировали (включили защиту от ДДОС и прочее) и теперь jmeter просто отваливается по тайм-ауту, но через консоль и другие клиенты фтп работает
Какие есть мысли или способы в таком случае делать нагрузку?
AV
вайтлист?
N
К сожалению нет )
AV
тогда мастер-слэйв подход?
AV
грубо говоря распределенная нагрузка с разных хостов, чтобы с слэйвов была допустимая нагрузка и не отсеивалась антифродером
N
Так, можно чуть подробнее? Может быть есть уже готовые примеры такого подхода? Или статьи?
KK
Если хотят проверить сколько сервис выдержит, то зачем включают DDOS-защиту перед ним?
K
Так, можно чуть подробнее? Может быть есть уже готовые примеры такого подхода? Или статьи?
KY
Если хотят проверить сколько сервис выдержит, то зачем включают DDOS-защиту перед ним?
+
ЕЕ
Коллеги, всем привет
Столкнулся с такой проблемой:
Тестировал ftp-сервис на нагрузку, после пары падений его переконфигурировали (включили защиту от ДДОС и прочее) и теперь jmeter просто отваливается по тайм-ауту, но через консоль и другие клиенты фтп работает
Какие есть мысли или способы в таком случае делать нагрузку?
Столкнулся с такой проблемой:
Тестировал ftp-сервис на нагрузку, после пары падений его переконфигурировали (включили защиту от ДДОС и прочее) и теперь jmeter просто отваливается по тайм-ауту, но через консоль и другие клиенты фтп работает
Какие есть мысли или способы в таком случае делать нагрузку?
Можно попробовать подмену адресов у запросов (ip spoofing)
https://www.blazemeter.com/blog/using-ip-spoofing-simulate-requests-different-ip-addresses-jmeter/
https://www.blazemeter.com/blog/using-ip-spoofing-simulate-requests-different-ip-addresses-jmeter/
N
Спасибо!