Вихід через проксі не переносить ваш двигун JMeter

Припустімо, тестовий двигун в одному офісі використовує проксі в іншій країні. Сайт бачить публічний вихід проксі, а запит усе ще починається на офісній машині.

office engine → regional proxy → website

Це корисно для перевірки поведінки, яку вибирає видимий вихідний IP. Вимірюється шлях, що включає ділянку від офісу до проксі, ділянку від проксі до сайту та власну обробку проксі. Це не той самий шлях, що в клієнта, запущеного поруч із регіональним проксі.

Параметри HTTP-проксі в JMeter можуть вибрати цього посередника. Зберігайте вибраний endpoint разом із результатами тесту й переконайтеся, що використовувані семплери справді застосовують потрібне налаштування. Для дозволеної перевірки публічного сайту без облікових даних проксі список HTTP-проксі пропонує HTTP-кандидатів; перевірте спостережуваний вихід, перш ніж інтерпретувати регіональний результат.

Розміщуйте двигун там, де починається вимірювання

Якщо питання стосується навантаження, створюваного з іншого мережевого розташування, використовуйте двигуни в потрібних місцях через підтримувану віддалену схему JMeter або незалежно керовані запуски CLI. Розташування контролера не замінює мережеві точки старту двигунів.

Плануйте навантаження явно. Віддалені двигуни JMeter виконують увесь тестовий план; контролер не розподіляє одну кількість потоків між ними автоматично. Кілька двигунів з одним планом можуть створити більше сумарне навантаження, ніж очікує читач.

Вибирайте схему залежно від питання: видимий вихідний IP, регіональний мережевий шлях користувача або сумарне навантаження застосунку. Зафіксуйте цей вибір, щоб результат, обмежений проксі, не подавався як самостійна ємність сайту.