Мы уже как-то выяснили что это профдеформация)

Но как без этого подать равномерную нагрузку я хз 🤷‍♂

Всем привет.

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

Может кому то попадались интересные статьи - пришлите, пожалуйста
@smirnovqa @Ganeles может вам что-то попадалось

Есть ещё один вариант решения твоей проблемы:
Если JSON реально огромный, использование JSON-парсеров создаёт некоторую проблему - сперва нужно преобразовать весь ответ в объект, потом в нём искать. Это удобно, если нужно искать массив ID с сложными параметрами поиска.

Если же вам нужен один ID - проще воспользоваться текстовым поиском.
- либо регуляркой сразу найти нужный ID
- либо, если сходу не получается - можно сделать это в два приёма: сперва достать в переменную подходящий вам кусок ответа (например, с помощью web_reg_save_param)
а потом искать регуляркой уже внутри него (lr_save_param_regexp)

Пользоваться ею нужно так:
 lr_save_param_regexp (
   lr_eval_string("{Part_of_Json}"),
   strlen(lr_eval_string("{Part_of_Json}")),
   "RegExp=ТУТ_РЕГУЛЯРКА",
   "Ordinal=All",
   "ResultParam=param_name_ID",
   LAST);

Сходу не вспомнить ничего :(

прокачиваем воображение, урок первый:
-представь себе тысячу потоков и все они ничего не делают. есть ли разница в том, не делают ничего 1000 потоков или 10 тысяч поток, или 100500 тысяч потоков не делают ничего? разницы нет - почему? потому что потоки сами по себе ничто в нашем мире
урок второй:
-представь, что та же самая тысяча потоков делает всего 1 запрос за час. она делает его одновременно? нужно ли их сдвигать друг от друга чтобы они не делали его одновременно? нет, этот запрос сделает всего 1 счастливый поток, в какой то момент времени, который никак не будет зависеть от других потоков.
последний урок на пути к совершенству:
-представь 1000 потоков, которые делают 10 запросов в секунду, для единовременных 10 запросов в секунду, нужно всего 10 потоков, а это значит что 990 не делают в этот момент ничего и подключаются только тогда когда видят, что те 10 отважных потоков которые делали запросы в первую секунду, не успели освободиться чтобы сделать еще 10, тогда на помощь приходят еще 10. и опять ситуация в которой сдвигать ничего не нужно, никто не подает нагрузку всей волной, сколько бы там не было потоков. потоки не нужно рассинхронизировать потмоу что они не синхронны!
теперь ты излечился от скверны!)

Прямо дзен

меня еще можно переубедить, если рассказать мне зачем сдвигать потоки, но в свое кунг-фу я очень сильно уверовал - это будет тяжело!

ты ведь всё через Throughput Shaping Timer делаешь?
тредгруппы обычные или кастомные?

да через него, тред группа самая дефолтная

Я начинал с jmeter 2.3, тогда не советовали использовать troughput timer для большого количества потоков, считалось ненадежным

да во второй версии часто были проблемы, тогда надежнее всего было юзать констант трупут таймер и регулировать нагрузку потоками)

и не дай бог постпроцессоры тяжелые)

Ух.. Долго же ты писал

Теперь это нужно осознать.

У меня сегодня такая проблема возникла - jmeter - один тред, один сэмплер, keep alive активно, 800 запросов в секунду. В какой-то момент получаю ошибку adreess already in use. Кто-то сталкивался с этим?

Обращение было к REST Api на 8080

на вебсокетах столкнулся - думал это пробелма вебсокетов

а какие тайминги?

у меня около 4 часов иногда без этого живет, а иногда и 10 бежит