Visual Studio lent en un recurs compartit per VPN: per què desar es converteix en viatges d’anada i tornada

Una solució que s’obre en un segon des d’un disc local triga trenta segons a obrir-se des d’un recurs compartit a què s’arriba per un túnel. El túnel poques vegades és la causa per si sol. El que canvia és que les operacions que eren crides locals esdevenen viatges d’anada i tornada sincrònics, i l’editor n’executa diverses abans que aparegui la finestra. El mecanisme següent explica per què cadascuna és cara i quines pots eliminar.

Què fa l’editor mentre un fitxer està obert

Un editor amb seguiment de canvis manté una subscripció a cada fitxer que té obert. Un volum local serveix aquesta subscripció des del sistema de fitxers sense xarxa. A través d’un recurs compartit la mateixa funció pot degradar-se en lectures repetides de metadades, perquè el model de notificacions no es comporta igual sobre SMB. Desactivar el seguiment de canvis és un primer experiment raonable, ja que elimina una classe sencera de peticions sense tocar el túnel.

El sistema de projectes afegeix trànsit propi. Carregar una solució enumera directoris, llegeix fitxers de projecte i pot sondar SDK o paquets, i cada sonda és un viatge d’anada i tornada quan el camí és remot. Una solució amb molts projectes multiplica aquest recompte, i per això el temps d’obertura creix més de pressa del que suggeririen les mides dels fitxers.

Cerques de l’entorn que caduquen abans que aparegui el menú

Windows aporta una segona font de bloquejos que no té res a veure amb l’IDE. L’Explorador i les seves extensions d’entorn tornen a resoldre impressores, unitats mapejades i accessos directes usats abans, cada cop que s’obre un menú contextual. Quan aquests destins són en una xarxa a què el túnel no pot arribar, cada resolució es bloqueja fins que venç un temps d’espera, i només llavors es pinta el menú. Per això un clic dret pot penjar-se segons mentre el fitxer mateix s’obre amb normalitat.

Elimina els mapejos morts i les cues d’impressió, o conserva només els que existeixen a la xarxa on ets realment. El mateix raonament val per a qualsevol cosa que resolgui un camí en segon pla, incloent-hi les llistes de fitxers recents i les carpetes fixades.

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

Per què guanya una còpia de treball local

Treballar directament al recurs compartit és la pitjor configuració per a un cicle d’edició, compilació i prova, perquè l’editor, el compilador i el client de control de versions llegeixen cadascun aquests fitxers remots per separat. Cadascun paga el seu propi viatge, i una compilació en paga un per fitxer. Una còpia local amb pujades a través del repositori substitueix una allau de petits creuaments per un de sol intencionat. L’enllaç no ha millorat; el nombre de creuaments s’ha ensorrat.

Això és un canvi estructural i no un exercici d’ajust, i és exactament per això que funciona quan els paràmetres del túnel no ho fan. També fa evident el mode de fallada: si la compilació continua lenta amb una còpia local, el recurs compartit mai no va ser el problema.

Mou l’historial com un sol objecte

Quan el repositori mateix ha de creuar el túnel, envia l’historial en un sol objecte en lloc de recórrer-lo. Un paquet és un sol fitxer i per tant un sol trànsit, mentre que un checkout que recorre milers d’objectes solts costa milers de creuaments. Mercurial i Git tots dos admeten aquesta forma.

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

La revisió base és la part que cal encertar, perquè decideix quant historial viatja. Empaquetar-ho tot funciona i malbarata l’enllaç, mentre que empaquetar des de l’últim canvi comú només mou el que li falta a l’altra banda.

Mesura tres operacions abans de culpar l’amplada de banda

Mesura tres coses per separat: un fitxer petit obert, un directori llistat, un desament completat. Si les tres són lentes en proporció al nombre de fitxers, el cost són els viatges d’anada i tornada. Si una s’encalla mentre les altres van bé, sospita d’un temps d’espera contra un recurs inabastable i no de l’amplada de banda. Anota en quina xarxa era la màquina a cada execució, perquè un portàtil que es reconnecta a un altre perfil pot canviar la resposta entre intents.

Després repeteix les mateixes tres contra una còpia local del projecte. La diferència és el preu del recurs compartit, i és el número que cal citar quan algú proposa un enllaç més ràpid com a solució.