Visual Studio tregt på ei VPN-deling: kvifor lagring blir rundturar

Ei løysing som opnar på eitt sekund frå ein lokal disk brukar tretti sekund frå ei deling som ein når gjennom ein tunnel. Tunnelen er sjeldan årsaka i seg sjølv. Det som endrar seg, er at operasjonar som var lokale kall blir synkrone rundturar, og editoren utfører fleire av dei før vindauga kjem til syne. Mekanismen nedanfor forklarer kvifor kvar einskild er dyr og kva du kan fjerne.

Kva editoren gjer medan ei fil er open

Ein editor med endringssporing held eit abonnement på kvar fil han har open. Eit lokalt volum tener det abonnementet frå filsystemet utan nett. Over ei deling kan den same funksjonen degenerere til gjentekne metadatalesingar, fordi varslingsmodellen ikkje oppfører seg likt over SMB. Å slå av endringssporing er eit rimeleg første eksperiment, sidan det fjernar ein heil klasse førespurnader utan å røre tunnelen.

Prosjektsystemet legg til sin eigen trafikk. Innlasting av ei løysing tel opp katalogar, les prosjektfiler og granskar kanskje SDK-ar eller pakkar, og kvar gransking er ein rundtur når stien er ekstern. Ei løysing med mange prosjekt multipliserer det talet, og difor veks opningstida raskare enn filstorleikane skulle tilseie.

Shell-oppslag som går ut før menyen kjem til syne

Windows bidreg med ei andre kjelde til stopp som ikkje har noko med IDE-en å gjere. Utforskaren og shell-utvidingane hans løyser på nytt skrivarar, tilkopla stasjonar og snarvegar som vart brukte før, kvar gong ein kontekstmeny opnar. Når desse måla ligg på eit nett som tunnelen ikkje når, blokkerer kvar oppløysing til ein tidsavbrot går ut, og først då blir menyen teikna. Difor kan ein høgreklikk henge i sekund medan sjølve fila opnar normalt.

Fjern dei døde tilkoplingane og skrivarkøane, eller hald berre dei som finst på nettet du faktisk er på. Same resonnementet dekkjer alt som løyser ein sti i bakgrunnen, inkludert lister over nylege filer og festa mapper.

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

Kvifor ein lokal arbeidskopi vinn

Å arbeide direkte på delinga er det dårlegaste oppsettet for ei løkke med redigering, bygging og testing, fordi editoren, kompilatoren og versjonskontrollklienten kvar les desse eksterne filene separat. Kvar av dei betaler sin eigen rundtur, og ein bygg betaler éin gong per fil. Ein lokal kopi med push gjennom repositoriet erstattar ein flaum av små kryssingar med éi medviten. Sambandet er ikkje blitt betre; talet på kryssingar har kollapsa.

Det er ei strukturell endring og ikkje ein tuneøving, og det er nettopp difor det verkar når tunnelinnstillingar ikkje gjer det. Det gjer òg feilmodusen openberr: om bygginga framleis er treg med ein lokal kopi, var delinga aldri problemet.

Flytt historikken som eitt objekt

Når repositoriet sjølv må krysse tunnelen, send historikken i eitt objekt i staden for å gå gjennom han. Ein bundle er éi fil og dermed éin overføring, medan ein checkout som går gjennom tusentals lause objekt kostar tusentals kryssingar. Mercurial og Git støttar begge den forma.

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

Basisrevisjonen er delen som må treffast, fordi han avgjer kor mykje historikk som reiser. Å bunte alt verkar og sløser med sambandet, medan bunting frå den siste felles endringa berre flyttar det den andre sida manglar.

Mål tre operasjonar før du klandrar bandbreidda

Mål tre ting kvar for seg: éi lita fil opna, éin katalog oppført, éi lagring fullført. Om alle tre er trege i høve til filtalet, er kostnaden rundturar. Om éin heng medan dei andre er fine, mistenk eit tidsavbrot mot ein utilgjengeleg ressurs og ikkje bandbreidda. Noter kva nett maskina var på for kvar køyring, fordi ein berbar PC som koplar til ein annan profil på nytt kan endre svaret mellom forsøk.

Gjenta så dei same tre mot ein lokal kopi av prosjektet. Skilnaden er prisen på delinga, og det er talet du skal sitere når nokon føreslår eit raskare samband som løysing.