Visual Studio lento su una condivisione VPN: perché i salvataggi diventano andate e ritorni

Una soluzione che si apre in un secondo da un disco locale impiega trenta secondi ad aprirsi da una condivisione raggiunta tramite un tunnel. Il tunnel raramente è la causa di per sé. Ciò che cambia è che operazioni che erano chiamate locali diventano andate e ritorni sincroni, e l’editor ne esegue diverse prima che appaia la finestra. Il meccanismo qui sotto spiega perché ciascuna è costosa e quali è possibile eliminare.

Che cosa fa l’editor mentre un file è aperto

Un editor con tracciamento delle modifiche mantiene una sottoscrizione su ogni file aperto. Un volume locale serve quella sottoscrizione dal file system senza rete. Attraverso una condivisione la stessa funzione può degradarsi in letture ripetute di metadati, perché il modello di notifica non si comporta allo stesso modo su SMB. Disattivare il tracciamento delle modifiche è un primo esperimento ragionevole, dato che elimina un’intera classe di richieste senza toccare il tunnel.

Il sistema di progetti aggiunge traffico proprio. Il caricamento di una soluzione enumera directory, legge file di progetto e può sondare SDK o pacchetti, e ogni sondaggio è un’andata e ritorno quando il percorso è remoto. Una soluzione con molti progetti moltiplica quel conteggio, per questo il tempo di apertura cresce più in fretta di quanto suggerirebbero le dimensioni dei file.

Ricerche della shell che scadono prima che il menu appaia

Windows aggiunge una seconda fonte di blocchi che non ha nulla a che vedere con l’IDE. Esplora risorse e le sue estensioni della shell risolvono di nuovo stampanti, unità mappate e collegamenti già usati ogni volta che si apre un menu contestuale. Quando quei bersagli si trovano su una rete che il tunnel non raggiunge, ogni risoluzione si blocca finché non scade un timeout, e solo allora il menu viene disegnato. Per questo un clic destro può bloccarsi per secondi mentre il file stesso si apre normalmente.

Rimuovi le mappature morte e le code di stampa, oppure conserva solo quelle che esistono sulla rete in cui ti trovi davvero. Lo stesso ragionamento vale per tutto ciò che risolve un percorso in background, compresi gli elenchi di file recenti e le cartelle aggiunte.

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

Perché vince una copia di lavoro locale

Lavorare direttamente sulla condivisione è la peggiore configurazione per un ciclo di modifica, compilazione e test, perché l’editor, il compilatore e il client di controllo versione leggono ciascuno quei file remoti separatamente. Ognuno paga la propria andata e ritorno, e una compilazione ne paga una per file. Una copia locale con push attraverso il repository sostituisce una marea di piccoli attraversamenti con uno solo intenzionale. Il collegamento non è migliorato; il numero di attraversamenti è crollato.

È un cambiamento strutturale e non un esercizio di regolazione, ed è esattamente per questo che funziona quando le impostazioni del tunnel non funzionano. Rende anche ovvio il modo di guasto: se la compilazione è ancora lenta con una copia locale, la condivisione non è mai stata il problema.

Sposta la cronologia come un solo oggetto

Quando il repository stesso deve attraversare il tunnel, invia la cronologia in un solo oggetto invece di percorrerla. Un bundle è un solo file e quindi un solo trasferimento, mentre un checkout che percorre migliaia di oggetti sciolti costa migliaia di attraversamenti. Mercurial e Git supportano entrambi quella forma.

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

La revisione di base è la parte da centrare, perché decide quanta cronologia viaggia. Impacchettare tutto funziona e spreca il collegamento, mentre impacchettare dall’ultima modifica comune sposta solo ciò che manca all’altro lato.

Misura tre operazioni prima di dare la colpa alla larghezza di banda

Misura tre cose separatamente: un file piccolo aperto, una directory elencata, un salvataggio completato. Se tutte e tre sono lente in proporzione al numero di file, il costo sono le andate e ritorni. Se una si blocca mentre le altre vanno bene, sospetta un timeout verso una risorsa irraggiungibile e non la larghezza di banda. Annota su quale rete si trovava la macchina a ogni esecuzione, perché un portatile che si riconnette a un altro profilo può cambiare la risposta tra un tentativo e l’altro.

Poi ripeti le stesse tre contro una copia locale del progetto. La differenza è il prezzo della condivisione, ed è il numero da citare quando qualcuno propone un collegamento più veloce come soluzione.