L'uscita di un proxy non sposta il tuo motore JMeter
Separare la verifica di un'esperienza regionale basata sull'IP dalla misurazione dell'esperienza di rete di un generatore di carico situato in quella regione.
Supponiamo che un motore di test in un ufficio usi un proxy in un altro paese. Il sito web vede l'uscita pubblica del proxy, mentre la richiesta parte comunque dalla macchina dell'ufficio.
office engine → regional proxy → website
È utile per verificare il comportamento selezionato dall'IP di origine apparente. Misura un percorso che comprende il tratto ufficio-proxy, oltre al tratto proxy-sito web e all'elaborazione del proxy stesso. Non è lo stesso percorso di un client che parte accanto al proxy regionale.
Le opzioni proxy HTTP di JMeter possono selezionare quell'intermediario. Conserva l'endpoint scelto insieme ai risultati del test e assicurati che i sampler utilizzati consumino davvero l'impostazione prevista. Per una verifica consentita di un sito pubblico senza credenziali proxy, la lista di proxy HTTP offre candidati HTTP; verifica l'uscita osservata prima di interpretare un risultato regionale.
Colloca il motore dove inizia la misurazione
Quando la domanda riguarda il carico generato da un'altra posizione di rete, usa motori nelle posizioni previste tramite la disposizione remota supportata da JMeter o esecuzioni CLI gestite in modo indipendente. La posizione del controller non sostituisce i punti di partenza di rete dei motori.
Pianifica il carico in modo esplicito. I motori remoti di JMeter eseguono il piano di test completo; il controller non divide automaticamente un conteggio di thread tra loro. Più motori che eseguono lo stesso piano possono produrre un carico aggregato maggiore di quanto un lettore si aspetti.
Scegli il progetto in base alla domanda: un IP di uscita apparente, il percorso di rete regionale di un utente o il carico aggregato dell'applicazione. Registra quella scelta affinché un risultato limitato dal proxy non venga riportato come capacità autonoma del sito web.