Ein Proxy-Ausgang verschiebt nicht Ihre JMeter-Engine

Angenommen, eine Test-Engine in einem Büro nutzt einen Proxy in einem anderen Land. Die Website sieht den öffentlichen Ausgang des Proxys, während die Anfrage weiterhin auf dem Bürorechner beginnt.

office engine → regional proxy → website

Das ist nützlich, um Verhalten zu prüfen, das die scheinbare Quell-IP auswählt. Es misst einen Pfad, der sowohl die Strecke vom Büro zum Proxy als auch die Strecke vom Proxy zur Website und die Verarbeitung des Proxys selbst enthält. Es ist nicht derselbe Pfad wie bei einem Client, der neben dem regionalen Proxy startet.

Die HTTP-Proxy-Optionen von JMeter können diesen Vermittler auswählen. Bewahren Sie den gewählten Endpunkt zusammen mit den Testergebnissen auf und stellen Sie sicher, dass die verwendeten Sampler tatsächlich die beabsichtigte Einstellung nutzen. Für eine erlaubte Prüfung öffentlicher Websites ohne Proxy-Zugangsdaten bietet die HTTP-Proxy-Liste HTTP-Kandidaten; prüfen Sie den beobachteten Ausgang, bevor Sie ein regionales Ergebnis interpretieren.

Setzen Sie die Engine dorthin, wo die Messung beginnt

Wenn die Frage die Last betrifft, die von einem anderen Netzwerkstandort erzeugt wird, verwenden Sie Engines an den vorgesehenen Standorten über die unterstützte Remote-Anordnung von JMeter oder eigenständig verwaltete CLI-Läufe. Der Standort des Controllers ersetzt nicht die Netzwerk-Ausgangspunkte der Engines.

Planen Sie die Last ausdrücklich. Remote-Engines von JMeter führen den vollständigen Testplan aus; der Controller verteilt eine Thread-Anzahl nicht automatisch auf sie. Mehrere Engines, die denselben Plan ausführen, können eine größere Gesamtlast erzeugen, als ein Leser erwartet.

Wählen Sie das Design nach der Fragestellung: eine scheinbare Ausgangs-IP, den regionalen Netzwerkpfad eines Nutzers oder die aggregierte Anwendungslast. Halten Sie diese Wahl fest, damit ein durch den Proxy begrenztes Ergebnis nicht als eigenständige Kapazität der Website gemeldet wird.