Изходът през прокси не мести вашия JMeter двигател

Да предположим, че тестов двигател в един офис използва прокси в друга държава. Сайтът вижда публичния изход на проксито, докато заявката все още започва на офис машината.

office engine → regional proxy → website

Това е полезно за проверка на поведение, избирано от привидния изходен IP. Измерва се път, който включва отсечката от офиса до проксито, както и отсечката от проксито до сайта и собствената обработка на проксито. Това не е същият път като на клиент, който стартира до регионалното прокси.

Опциите за HTTP прокси в JMeter могат да изберат този посредник. Съхранявайте избрания endpoint заедно с резултатите от теста и се уверете, че използваните семплъри наистина прилагат предвидената настройка. За разрешена проверка на публичен сайт без прокси идентификационни данни списъкът с HTTP проксита предлага HTTP кандидати; проверете наблюдавания изход, преди да тълкувате регионален резултат.

Поставете двигателя там, където започва измерването

Когато въпросът засяга натоварване, генерирано от друго мрежово място, използвайте двигатели в предвидените места чрез поддържаната отдалечена схема на JMeter или независимо управлявани CLI изпълнения. Местоположението на контролера не замества мрежовите начални точки на двигателите.

Планирайте натоварването изрично. Отдалечените двигатели на JMeter изпълняват целия тестов план; контролерът не разпределя автоматично един брой нишки между тях. Няколко двигателя, изпълняващи един и същ план, могат да създадат по-голямо общо натоварване, отколкото читателят очаква.

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