Ieșirea prin proxy nu mută motorul JMeter

Să presupunem că un motor de test dintr-un birou folosește un proxy din altă țară. Site-ul vede ieșirea publică a proxy-ului, în timp ce cererea începe tot de pe mașina biroului.

office engine → regional proxy → website

Acest lucru este util pentru verificarea comportamentului selectat de IP-ul sursă aparent. Se măsoară o cale care include atât segmentul de la birou la proxy, cât și segmentul de la proxy la site și procesarea proxy-ului însuși. Nu este aceeași cale ca a unui client care pornește lângă proxy-ul regional.

Opțiunile de proxy HTTP din JMeter pot selecta acel intermediar. Păstrați endpoint-ul ales împreună cu rezultatele testului și asigurați-vă că sampler-ele folosite aplică într-adevăr setarea dorită. Pentru o verificare permisă a unui site public fără acreditări de proxy, lista de proxy-uri HTTP oferă candidați HTTP; verificați ieșirea observată înainte de a interpreta un rezultat regional.

Plasați motorul acolo unde începe măsurarea

Când întrebarea privește încărcarea generată dintr-o altă locație de rețea, folosiți motoare în locațiile dorite prin aranjamentul la distanță acceptat de JMeter sau prin rulări CLI administrate independent. Locația controlerului nu înlocuiește punctele de pornire în rețea ale motoarelor.

Planificați încărcarea în mod explicit. Motoarele la distanță din JMeter rulează planul de test complet; controlerul nu împarte automat un număr de fire între ele. Mai multe motoare care rulează același plan pot produce o încărcare totală mai mare decât se așteaptă un cititor.

Alegeți proiectarea în funcție de întrebare: un IP de ieșire aparent, calea de rețea regională a unui utilizator sau încărcarea totală a aplicației. Înregistrați această alegere pentru ca un rezultat limitat de proxy să nu fie raportat ca capacitate independentă a site-ului.