по логам эмуль доходит прям до самого отправления ответа

но потом что-то ломается в нем, и клиент не получает ответ

Заглушку вешаете на тот же порт что и на старых серверах?

Иными словами, курлите в куда, и в куда отвечает заглушка

Вероятно, туда куда пытается ответить заглушка, занято.

Нашел 😅 проблему, оказалось напутал со сборками и не тот код улетел на генератор 🤦‍♂

Но спасибо большое за участие! 🙏

Доброго здравия всем, товарищи! Прошу помочь разобраться, возможно, кто-то имел дело с подобной проблемой. Столкнулись с тем, что на одних и тех же запросах в одном случае connect time может быть до 60мс, а в другой раз до 120 секунд. Репродьюсится только при запуске теста с нашего лоадгенератора, что в AWS. При прочих равных условиях и запуске локально со своей машины – идеально ходит тест. При запуске с этого же лоадгенератора, но на другой энв – не репродьюсится, идеально ходит тест. Думаем, в сети проблема, найти бы где. По Jmeter данным получаем именно connect time большой. Если отнять его от latency – то будет примерно такое же время, какое показывают наши логи по обработке этого запроса на серверной части.
В какую сторону советуете копать? Какие инструменты можете посоветовать, чтобы отследить полный путь запроса по сети от лоадгенератора до сервера и обратно? Возможно, есть у jmeter плагин для сего или какое-то advanced логирование? Мерси.

на определенных семплерах? препроцессоры стоят сложные?

а, хм. при смене энва не воспроизводится, тогда интересная история

подумаю

я бы просто из любой IDE на любом языке попробовал коннекты покидать с замерами

какие есть ещё свойства проблемы? начинается с определённого момента, принадлежит определенным запросам? частота из теста в тест одинаковая?

изначально вообще можно немного уйти от нее и сделать в тред группе галочку same user each iteration

Все предпроцессоры отключили. Несколько http запросов: логин, открыть 1ю, 2ю страницы.

Начинается по-разному. Обычно после 20-30 нормальных запросов идёт 2-10 с огромным connect time. Далее опять нормально. Периодичность есть, но не стабильная, всегда по-разному. Проблема не принадлежит определённым запросам. Репродьюсится на самых разных. Частота примерно 15-20% тяжёлых на 80-85% нормальных. Продебажили бэк - там быстрая обработка. Мониторили базу, аппл - вообще нет серьёзных нагрузок. Да и не может быть, даже на парочке vu репродьюсится

Наши автоматизаторы на этом же энве свои тесты пробовали. Локально через UI не репродьюсится, локально через их IDE тоже. А вот теже их тесты, но через дженкинс в AWS - в разное время тесты валятся на разных моментах из-за 120 сек задержек

да с сеткой проблема, а какая архитектура?

Бэк на php, один аппл сервер, db percona proxy, который на один из 3х db node отсылает. Всё в aws. LB стоит перед аппл серваком

Добро, проблема с сеткой. Как советуете попробовать отследить это в связке с работающим jmeter?