Size: a a a

QA — Load & Performance

2020 September 17

A

Alexander in QA — Load & Performance
У меня почти моментально
источник

KY

Kirill Yurkov in QA — Load & Performance
честно - не совсем понимаю этот экспешн и не копал его еще
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Kirill Yurkov
прокачиваем воображение, урок первый:
-представь себе тысячу потоков и все они ничего не делают. есть ли разница в том, не делают ничего 1000 потоков или 10 тысяч поток, или 100500 тысяч потоков не делают ничего? разницы нет - почему? потому что потоки сами по себе ничто в нашем мире
урок второй:
-представь, что та же самая тысяча потоков делает всего 1 запрос за час. она делает его одновременно? нужно ли их сдвигать друг от друга чтобы они не делали его одновременно? нет, этот запрос сделает всего 1 счастливый поток, в какой то момент времени, который никак не будет зависеть от других потоков.
последний урок на пути к совершенству:
-представь 1000 потоков, которые делают 10 запросов в секунду, для единовременных 10 запросов в секунду, нужно всего 10 потоков, а это значит что 990 не делают в этот момент ничего и подключаются только тогда когда видят, что те 10 отважных потоков которые делали запросы в первую секунду, не успели освободиться чтобы сделать еще 10, тогда на помощь приходят еще 10. и опять ситуация в которой сдвигать ничего не нужно, никто не подает нагрузку всей волной, сколько бы там не было потоков. потоки не нужно рассинхронизировать потмоу что они не синхронны!
теперь ты излечился от скверны!)
Я согласен что потоки активны до конца теста, и каждый поток выполняет операцию в заданное время. Конкретно в начале каждой новой минуты. И все потоки это делают одновременно, что приводит к пиле.
источник

KY

Kirill Yurkov in QA — Load & Performance
Вячеслав Поляков
Я согласен что потоки активны до конца теста, и каждый поток выполняет операцию в заданное время. Конкретно в начале каждой новой минуты. И все потоки это делают одновременно, что приводит к пиле.
а откуда информация про минуты?
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Я сам указываю.
источник

KY

Kirill Yurkov in QA — Load & Performance
если ты задал 10 запросов в секунду, оно не может выполняться в начале каждой новой минуты
источник

A

Alexander in QA — Load & Performance
У меня коллега это так объяснил, jMeter блокирует порт для отправки запроса, если пул портов уже исчерпан, то берет уже использованный, а тот может быть еще не освобожден. Отсюда ошибка. Система Windows
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Kirill Yurkov
если ты задал 10 запросов в секунду, оно не может выполняться в начале каждой новой минуты
Указываю в utg
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Там я говорю что выполнять данную операцию 1 раз в минуту.
источник

KY

Kirill Yurkov in QA — Load & Performance
Alexander
У меня коллега это так объяснил, jMeter блокирует порт для отправки запроса, если пул портов уже исчерпан, то берет уже использованный, а тот может быть еще не освобожден. Отсюда ошибка. Система Windows
тогда бы в event log упала бы ошибка с кодом 4227 или 4231, source TCP/IP и проблема была бы в открытых сокетах - их максимум 65к, это и есть доступный пул портов
источник

KY

Kirill Yurkov in QA — Load & Performance
Вячеслав Поляков
Указываю в utg
покажи как ты в натройках тред группы указываешь интенсивность
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Kirill Yurkov
покажи как ты в натройках тред группы указываешь интенсивность
Давай уже завтра.
источник

KY

Kirill Yurkov in QA — Load & Performance
давай
источник

KY

Kirill Yurkov in QA — Load & Performance
но если что тред группа оперирует треды а таймеры запросами, и в тредах нельзя укаказать количество запросов
источник

KY

Kirill Yurkov in QA — Load & Performance
:)
источник

EP

Egor Parkhomenko in QA — Load & Performance
Viktor 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);
Спасибо за ответ! Там json из рандомных id и т.п  с одинаковым именем, но условие по которому можно осуществить выборку находится после необходимого id в json-e.
Текстовые может и подойдут, но проблема в условии которое нужно записать
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Kirill Yurkov
но если что тред группа оперирует треды а таймеры запросами, и в тредах нельзя укаказать количество запросов
В моем случае тред - пользователь выполняющий энное количество операций в минуту.
источник

ВП

Вячеслав Поляков... in QA — Load & Performance
Опереция - набор реквестов
источник

KY

Kirill Yurkov in QA — Load & Performance
завтра давай действительно глянем
источник

VG

Viktor Ganeles in QA — Load & Performance
Egor Parkhomenko
Спасибо за ответ! Там json из рандомных id и т.п  с одинаковым именем, но условие по которому можно осуществить выборку находится после необходимого id в json-e.
Текстовые может и подойдут, но проблема в условии которое нужно записать
Давай json
Если большой - можно и в личку
источник