Een proxy-uitgang verplaatst je JMeter-engine niet

Stel dat een testengine in het ene kantoor een proxy in een ander land gebruikt. De website ziet de openbare uitgang van de proxy, terwijl het verzoek nog steeds op de kantoormachine begint.

office engine → regional proxy → website

Dat is nuttig om gedrag te controleren dat door het schijnbare bron-IP wordt gekozen. Het meet een pad dat zowel het traject van kantoor naar proxy als het traject van proxy naar website en de verwerking van de proxy zelf omvat. Het is niet hetzelfde pad als dat van een client die naast de regionale proxy start.

De HTTP-proxyopties van JMeter kunnen die tussenpartij kiezen. Bewaar het gekozen endpoint bij de testresultaten en zorg dat de gebruikte samplers daadwerkelijk de bedoelde instelling gebruiken. Voor een toegestane controle van een openbare site zonder proxyreferenties biedt de HTTP-proxylijst HTTP-kandidaten; controleer de waargenomen uitgang voordat je een regionaal resultaat interpreteert.

Plaats de engine waar de meting begint

Als de vraag gaat over belasting die vanuit een andere netwerklocatie wordt gegenereerd, gebruik dan engines op de bedoelde locaties via de ondersteunde externe opstelling van JMeter of onafhankelijk beheerde CLI-runs. De locatie van de controller vervangt niet de netwerkstartpunten van de engines.

Plan de belasting expliciet. De externe engines van JMeter voeren het volledige testplan uit; de controller verdeelt niet automatisch één threadaantal onder hen. Meerdere engines die hetzelfde plan uitvoeren, kunnen een grotere totale belasting produceren dan een lezer verwacht.

Kies het ontwerp op basis van de vraag: een schijnbaar uitgangs-IP, het regionale netwerkpad van een gebruiker of de totale applicatiebelasting. Leg die keuze vast, zodat een door de proxy beperkt resultaat niet wordt gerapporteerd als de zelfstandige capaciteit van de website.