Tegyük fel, hogy az egyik irodában lévő tesztmotor egy másik országban lévő proxyt használ. A webhely látja a proxy nyilvános kimenetét, a kérés viszont továbbra is az irodai gépen indul.

office engine → regional proxy → website

Ez hasznos a látszólagos forrás-IP által kiválasztott viselkedés ellenőrzéséhez. Olyan útvonalat mér, amely magában foglalja az irodától a proxyig tartó szakaszt, valamint a proxytól a webhelyig tartó szakaszt és a proxy saját feldolgozását. Ez nem ugyanaz az útvonal, mint egy regionális proxy mellett induló kliensé.

A JMeter HTTP-proxy beállításai kiválaszthatják ezt a közvetítőt. Őrizd meg a kiválasztott végpontot a teszt eredményeivel együtt, és győződj meg arról, hogy a használt samplerek valóban a szánt beállítást alkalmazzák. Egy engedélyezett nyilvános webhely-ellenőrzéshez proxy-hitelesítő adatok nélkül a HTTP-proxy lista HTTP-jelölteket kínál; a regionális eredmény értelmezése előtt ellenőrizd a megfigyelt kimenetet.

Helyezd a motort oda, ahol a mérés elkezdődik

Amikor a kérdés egy másik hálózati helyről származó terhelésre vonatkozik, használj motorokat a kívánt helyeken a JMeter támogatott távoli elrendezésén vagy önállóan kezelt CLI-futtatásokon keresztül. A vezérlő helye nem helyettesíti a motorok hálózati kiindulópontjait.

Tervezd meg a terhelést kifejezetten. A JMeter távoli motorjai a teljes teszttervet futtatják; a vezérlő nem osztja el automatikusan az egyik szálszámot közöttük. Több motor, amely ugyanazt a tervet futtatja, nagyobb összesített terhelést eredményezhet, mint amire egy olvasó számít.

A kérdés alapján válaszd ki a kialakítást: látszólagos kimeneti IP, a felhasználó regionális hálózati útvonala vagy az alkalmazás összesített terhelése. Jegyezd fel ezt a választást, hogy a proxy által korlátozott eredmény ne a webhely önálló kapacitásaként legyen jelentve.

Kapcsolódó cikkek