Prima di dare la colpa alla VPN, misurate il percorso con iperf3

Le copie di file tra due sedi sembrano test di rete, ma ciascuna è un risultato composito: overhead del protocollo, archiviazione su entrambi i lati, elaborazione sull'endpoint e il percorso. Dare la colpa alla VPN soltanto da quel numero è un'ipotesi. Un flusso breve e controllato tra gli stessi endpoint fornisce una seconda osservazione, ed è il confronto a mostrare quale parte merita attenzione. Il piano qui sotto lo fa senza inventare risultati.

Una copia di file è un carico di lavoro, non una misura

La larghezza di banda è una proprietà di un percorso, mentre la copia di file misura più proprietà insieme. Molti file piccoli stressano le operazioni per file molto più di un unico flusso grande. Un'archiviazione lenta su uno dei due lati limita la copia indipendentemente dal tunnel. Crittografia e incapsulamento aggiungono overhead, ma lo fa anche un file server che calcola checksum o esegue scansioni antivirus. Solo un confronto che mantiene costanti endpoint e direzione separa quei contributi.

I test di velocità pubblici misurano un percorso verso un server di test vicino, che non è il percorso verso il vostro file server privato. Rispondono a una domanda diversa.

Eseguite un flusso una tantum in ciascuna direzione

Quando entrambe le estremità sono sotto il vostro controllo, pianificate un'esecuzione breve di iperf3 in una finestra approvata. Usate il file server come endpoint remoto quando possibile e annotatelo quando al suo posto viene usato un host sostitutivo.

iperf3 -s -1 -B 10.77.0.20

Il server si lega a un indirizzo privato e accetta un solo client prima di uscire. Un listener una tantum non scade da solo quando non arriva alcun client, quindi fermarlo alla chiusura della finestra approvata.

iperf3 -c 10.77.0.20 -t 10

Per impostazione predefinita il client invia al server su TCP 5201, e una finestra di dieci secondi mantiene breve il test. Limitate il listener nel firewall all'origine e alla destinazione private previste invece di esporlo pubblicamente.

iperf3 -c 10.77.0.20 -t 10 -R

L'opzione inversa rende il server il mittente, cosa che conta perché i percorsi di upload e download spesso differiscono. Legare un indirizzo non prova che il client abbia scelto il percorso previsto, quindi registrate il percorso realmente testato. Conservate stato della VPN, direzione, durata e carico dell'endpoint insieme ai risultati, poi rimuovete l'accesso temporaneo.

Confrontate ciò che è confrontabile

Ripetete un'operazione di file rappresentativa in condizioni simili, con lo stesso endpoint di servizio e senza modifiche di configurazione non correlate nel mezzo. Annotate se è un upload o un download, un solo file grande o molti piccoli, e se l'archiviazione su uno dei due lati è occupata. Un breve picco non è la velocità sostenuta dell'intera copia, e nessuna delle due osservazioni deve diventare silenziosamente l'altra. Se sia il flusso sia la copia sono lenti nella stessa direzione, guardate il percorso condiviso e i limiti dell'endpoint.

Quando il flusso è sano e la copia no, la differenza è ciò che aggiunge il carico di lavoro, ed è lì che va la prossima indagine.

Leggete le unità prima di trarre conclusioni

I megabit al secondo e i megabyte al secondo differiscono di un fattore otto, e i thread di assistenza confrontano abitualmente i due come se fossero la stessa unità. Un risultato iperf3 basso può anche venire dall'host di test stesso: saturazione della CPU, un'interfaccia lenta o un disco occupato possono limitare il processo prima della rete. Per questo un solo numero non è un verdetto contro il provider o il protocollo. La baseline è utile perché è osservata invece che presunta, e restringe la domanda a una direzione e a un endpoint.

Annotate endpoint, direzione, durata e velocità per entrambe le osservazioni. Quel quartetto rende difendibile il confronto, e costa molto meno che sostituire software per intuizione.