I file piccoli strisciano sulla VPN per i viaggi di andata e ritorno, non per la velocità

Copiate un file da 2 GB sulla VPN e il trasferimento sembra a posto. Copiate una cartella di diecimila piccoli documenti e lo stesso collegamento sembra rotto. La differenza non è un’impostazione di larghezza di banda cambiata tra i due lavori. Il secondo lavoro passa il tempo in configurazione, metadati e attesa delle risposte, ed è la latenza del tunnel a rendere visibile quell’attesa.

Un file va in streaming; una cartella di file negozia

Una copia grande passa la maggior parte della sua vita in un ciclo di lettura e scrittura su pochi handle aperti. Il costo del protocollo si paga una volta per file, e i dati si muovono in blocchi grandi. La larghezza di banda domina il risultato.

Una copia di cartella paga per ogni file: creare, interrogare gli attributi, aprire, scrivere, chiudere e aggiornare i metadati della directory. Ognuna di queste è una richiesta che attende una risposta prima che il passo successivo possa procedere. I byte sono minuscoli; il coordinamento non lo è.

Per questo un grafico di basso utilizzo del collegamento non dimostra quasi nulla. Il collegamento è inattivo perché il client attende, non perché il tunnel è lento. Un array di storage o uno scanner di endpoint possono aggiungere la stessa forma di ritardo. Identificate quale fase attende prima di cambiare qualsiasi impostazione di rete.

I viaggi di andata e ritorno si sommano più in fretta dei byte

La latenza è il costo di uno scambio dipendente. Se un file richiede diversi scambi serializzati e il tunnel aggiunge 40 ms in ciascuna direzione, il costo per file cresce rapidamente. Diecimila file lo trasformano in minuti.

L’aritmetica è illustrativa, non una misurazione: non è detto che un file costi un solo viaggio di andata e ritorno, e i client sovrappongono parte del lavoro.

Due leve cambiano il totale. Riducete il numero di scambi dipendenti per file, oppure tenetene di più in volo contemporaneamente. La prima è un cambio di protocollo o di carico; la seconda è la concorrenza. Nessuna delle due rende più veloce un collegamento lento.

Misurate il carico di lavoro, non il collegamento

Confrontate tre lavori con gli stessi endpoint e la stessa politica di accesso: un file grande, la cartella di file piccoli e l’operazione di business reale. Annotate numero di file, distribuzione delle dimensioni, strumento di copia e condizioni di rete con ogni risultato.

Un solo numero in MB/s senza quei dettagli non si può confrontare con quello di nessun altro.

Misurate la latenza separatamente dal throughput. Un semplice test di andata e ritorno verso il file server dà il numero che si moltiplica sulle operazioni piccole. Poi osservate il modello di richieste della copia invece del suo tasso medio. Se il tasso è basso e il collegamento è inattivo, il collo di bottiglia è sopra il tunnel.

Cambiate il lavoro: concorrenza e archivi

Per una copia massiva autorizzata, uno strumento con concorrenza controllata mantiene più richieste in volo. L’opzione /MT di Robocopy è l’esempio comune su Windows. Aggiungere thread non garantisce una copia più rapida.

Scegliete un numero che client, server e storage possano sostenere, e conservate il registro del lavoro e gli eventuali errori.

Archiviare alla fonte e decomprimere in locale elimina il lavoro remoto per file. Includete il tempo di preparazione ed estrazione nel confronto e confermate che l’archivio conservi i metadati e i permessi necessari al lavoro. Nessuno dei due trucchi fa raggruppare a un’applicazione le proprie operazioni sui file.

Verificate il contatore con un test controllato

Eseguite due volte lo stesso lavoro cambiando una variabile, e annotate entrambi i numeri. Un test controllato è l’unico modo per sapere se un’impostazione ha aiutato o se la rete era più tranquilla per caso.

Due comandi danno il numero di file e la linea di base di andata e ritorno:

Get-ChildItem \\fileserver.hq.example\\share -Recurse | Measure-Object -Property Length -Sum
ping -n 20 fileserver.hq.example

Poi eseguite la copia con un numero limitato di thread e confrontate il registro con l’esecuzione precedente:

robocopy \\fileserver.hq.example\\share C:\\local /E /MT:16 /LOG:copy.log /TEE

Non disattivate la firma SMB, la crittografia o la protezione degli endpoint per migliorare il contatore. Quei cambiamenti scambiano una proprietà di sicurezza con un numero che forse non era il collo di bottiglia. E tenete il trasporto VPN separato dal trasporto proprio di SMB nelle vostre note, perché una correzione in uno non è prova sull’altro.