Les petits fichiers rampent sur le VPN à cause des allers-retours, pas de la vitesse

Copiez un fichier de 2 GB sur le VPN et le transfert semble correct. Copiez un dossier de dix mille petits documents et le même lien semble cassé. La différence n’est pas un réglage de bande passante qui aurait changé entre les deux travaux. Le second travail passe son temps en configuration, métadonnées et attente de réponses, et c’est la latence du tunnel qui rend cette attente visible.

Un fichier diffuse ; un dossier de fichiers négocie

Une grosse copie passe l’essentiel de sa vie dans une boucle de lecture-écriture sur un petit nombre de handles ouverts. Le coût du protocole est payé une fois par fichier, et les données circulent en gros blocs. La bande passante domine le résultat.

Une copie de dossier paie par fichier : créer, interroger les attributs, ouvrir, écrire, fermer et mettre à jour les métadonnées du répertoire. Chacune de ces étapes est une requête qui attend une réponse avant que l’étape suivante puisse avancer. Les octets sont minuscules ; la coordination ne l’est pas.

C’est pourquoi un graphique de faible utilisation du lien ne prouve presque rien. Le lien est inactif parce que le client attend, pas parce que le tunnel est lent. Une baie de stockage ou un scanner de point de terminaison peut ajouter la même forme de délai. Identifiez quelle étape attend avant de changer le moindre réglage réseau.

Les allers-retours s’additionnent plus vite que les octets

La latence est le coût d’un échange dépendant. Si un fichier exige plusieurs échanges sérialisés et que le tunnel ajoute 40 ms dans chaque sens, le coût par fichier grimpe vite. Dix mille fichiers transforment cela en minutes.

Le calcul est illustratif, pas une mesure : un fichier ne coûte pas forcément un aller-retour, et les clients chevauchent une partie du travail.

Deux leviers changent le total. Réduisez le nombre d’échanges dépendants par fichier, ou gardez-en davantage en vol à la fois. Le premier est un changement de protocole ou de charge de travail ; le second est la concurrence. Aucun des deux n’accélère un lien lent.

Mesurez la charge de travail, pas le lien

Comparez trois travaux avec les mêmes extrémités et la même politique d’accès : un gros fichier, le dossier de petits fichiers et l’opération métier réelle. Notez le nombre de fichiers, la distribution des tailles, l’outil de copie et les conditions réseau avec chaque résultat.

Un seul chiffre en MB/s sans ces détails ne peut être comparé à celui de personne d’autre.

Mesurez la latence séparément du débit. Un simple test d’aller-retour vers le serveur de fichiers donne le chiffre qui se multiplie sur les petites opérations. Observez ensuite le profil de requêtes de la copie plutôt que son débit moyen. Si le débit est faible et le lien inactif, le goulot d’étranglement se situe au-dessus du tunnel.

Changez le travail : concurrence et archives

Pour une copie en masse autorisée, un outil à concurrence contrôlée maintient plus de requêtes en vol. L’option /MT de Robocopy est l’exemple courant sous Windows. Ajouter des threads ne garantit pas une copie plus rapide.

Choisissez un nombre que le client, le serveur et le stockage peuvent soutenir, et conservez le journal du travail et les éventuelles erreurs.

Archiver à la source et décompresser localement supprime le travail distant par fichier. Incluez le temps de préparation et d’extraction dans la comparaison, et confirmez que l’archive préserve les métadonnées et les permissions dont la tâche a besoin. Aucune des deux astuces n’oblige une application à regrouper ses propres opérations de fichiers.

Vérifiez le compteur avec un test contrôlé

Exécutez deux fois le même travail en changeant une seule variable, et notez les deux chiffres. Un test contrôlé est le seul moyen de savoir si un réglage a aidé ou si le réseau était plus calme par hasard.

Deux commandes donnent le nombre de fichiers et la référence d’aller-retour :

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

Exécutez ensuite la copie avec un nombre de threads limité et comparez le journal à l’exécution précédente :

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

Ne désactivez pas la signature SMB, le chiffrement ou la protection des points de terminaison pour améliorer le compteur. Ces changements échangent une propriété de sécurité contre un chiffre qui n’était peut-être pas le goulot d’étranglement. Et gardez le transport VPN séparé du transport propre de SMB dans vos notes, car un correctif dans l’un ne prouve rien sur l’autre.