Visual Studio lent sur un partage VPN : pourquoi les enregistrements deviennent des allers-retours

Une solution qui s’ouvre en une seconde depuis un disque local met trente secondes à s’ouvrir depuis un partage atteint par un tunnel. Le tunnel est rarement la cause à lui seul. Ce qui change, c’est que des opérations qui étaient des appels locaux deviennent des allers-retours synchrones, et l’éditeur en effectue plusieurs avant que la fenêtre n’apparaisse. Le mécanisme ci-dessous explique pourquoi chacune coûte cher et lesquelles vous pouvez supprimer.

Ce que fait l’éditeur pendant qu’un fichier est ouvert

Un éditeur avec suivi des modifications maintient un abonnement sur chaque fichier ouvert. Un volume local sert cet abonnement depuis le système de fichiers sans réseau. À travers un partage, la même fonction peut dégénérer en lectures répétées de métadonnées, car le modèle de notification ne se comporte pas de la même façon sur SMB. Désactiver le suivi des modifications est une première expérience honnête, puisqu’elle retire toute une classe de requêtes sans toucher au tunnel.

Le système de projets ajoute son propre trafic. Le chargement d’une solution énumère des répertoires, lit des fichiers de projet et peut sonder des SDK ou des paquets, et chaque sonde est un aller-retour lorsque le chemin est distant. Une solution avec de nombreux projets multiplie ce nombre, ce qui explique pourquoi le temps d’ouverture croît plus vite que la taille des fichiers ne le suggère.

Des recherches du shell qui expirent avant l’apparition du menu

Windows apporte une seconde source de blocages qui n’a rien à voir avec l’IDE. L’Explorateur et ses extensions shell résolvent à nouveau les imprimantes, les lecteurs mappés et les raccourcis déjà utilisés chaque fois qu’un menu contextuel s’ouvre. Quand ces cibles se trouvent sur un réseau que le tunnel ne peut pas atteindre, chaque résolution bloque jusqu’à l’expiration d’un délai, et le menu ne se peint qu’ensuite. C’est pourquoi un clic droit peut rester bloqué des secondes alors que le fichier lui-même s’ouvre normalement.

Supprimez les mappages morts et les files d’impression, ou ne gardez que ceux qui existent sur le réseau où vous êtes réellement. Le même raisonnement couvre tout ce qui résout un chemin en arrière-plan, y compris les listes de fichiers récents et les dossiers épinglés.

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

Pourquoi une copie de travail locale gagne

Travailler directement sur le partage est la pire configuration pour une boucle édition-compilation-test, car l’éditeur, le compilateur et le client de gestion de versions lisent chacun ces fichiers distants séparément. Chacun paie son propre aller-retour, et une compilation en paie un par fichier. Une copie locale avec des poussées via le dépôt remplace un flot de petites traversées par une seule intentionnelle. La liaison ne s’est pas améliorée ; le nombre de traversées s’est effondré.

C’est un changement structurel et non un exercice de réglage, et c’est exactement pourquoi il fonctionne quand les réglages du tunnel ne fonctionnent pas. Il rend aussi le mode de défaillance évident : si la compilation reste lente avec une copie locale, le partage n’a jamais été le problème.

Déplacez l’historique comme un seul objet

Quand le dépôt lui-même doit traverser le tunnel, envoyez l’historique en un seul objet au lieu de le parcourir. Un bundle est un seul fichier et donc un seul transfert, alors qu’un checkout qui parcourt des milliers d’objets isolés coûte des milliers de traversées. Mercurial et Git prennent tous deux en charge cette forme.

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

La révision de base est la partie à réussir, car elle décide de la quantité d’historique qui voyage. Tout empaqueter fonctionne et gaspille la liaison, tandis qu’empaqueter depuis la dernière modification commune ne déplace que ce qui manque à l’autre côté.

Mesurez trois opérations avant d’accuser la bande passante

Mesurez trois choses séparément : un petit fichier ouvert, un répertoire listé, un enregistrement terminé. Si les trois sont lentes proportionnellement au nombre de fichiers, le coût est fait d’allers-retours. Si l’une bloque alors que les autres vont bien, soupçonnez un délai d’expiration contre une ressource inaccessible et non la bande passante. Notez sur quel réseau se trouvait la machine à chaque exécution, car un portable qui se reconnecte à un autre profil peut changer la réponse entre deux essais.

Répétez ensuite les mêmes trois contre une copie locale du projet. La différence est le prix du partage, et c’est le chiffre à citer quand quelqu’un propose une liaison plus rapide comme solution.