Une sortie proxy ne déplace pas votre moteur JMeter

Supposons qu'un moteur de test dans un bureau utilise un proxy dans un autre pays. Le site web voit la sortie publique du proxy, alors que la requête commence toujours sur la machine du bureau.

office engine → regional proxy → website

C'est utile pour vérifier le comportement sélectionné par l'IP source apparente. Cela mesure un chemin qui comprend le tronçon bureau-proxy, ainsi que le tronçon proxy-site web et le traitement du proxy lui-même. Ce n'est pas le même chemin qu'un client qui démarre à côté du proxy régional.

Les options de proxy HTTP de JMeter peuvent sélectionner cet intermédiaire. Conservez le point de terminaison choisi avec les résultats du test et assurez-vous que les samplers utilisés consomment réellement le réglage prévu. Pour une vérification autorisée d'un site public sans identifiants de proxy, la liste de proxies HTTP propose des candidats HTTP ; vérifiez la sortie observée avant d'interpréter un résultat régional.

Placez le moteur là où commence la mesure

Lorsque la question porte sur une charge générée depuis un autre emplacement réseau, utilisez des moteurs aux emplacements prévus via la disposition distante prise en charge par JMeter ou des exécutions CLI gérées indépendamment. L'emplacement du contrôleur ne remplace pas les points de départ réseau des moteurs.

Planifiez la charge explicitement. Les moteurs distants de JMeter exécutent le plan de test complet ; le contrôleur ne répartit pas automatiquement un nombre de threads entre eux. Plusieurs moteurs exécutant le même plan peuvent produire une charge agrégée plus importante qu'un lecteur ne l'attend.

Choisissez la conception en fonction de la question : une IP de sortie apparente, le chemin réseau régional d'un utilisateur ou la charge agrégée de l'application. Consignez ce choix afin qu'un résultat limité par le proxy ne soit pas présenté comme la capacité autonome du site web.