Visual Studio tregt på en VPN-deling: hvorfor lagring blir rundturer

En løsning som åpnes på ett sekund fra en lokal disk bruker tretti sekunder fra en deling som nås gjennom en tunnel. Tunnelen er sjelden årsaken i seg selv. Det som endres, er at operasjoner som var lokale kall blir synkrone rundturer, og editoren utfører flere av dem før vinduet vises. Mekanismen nedenfor forklarer hvorfor hver enkelt er dyr og hvilke du kan fjerne.

Hva editoren gjør mens en fil er åpen

En editor med endringssporing holder et abonnement på hver fil den har åpen. Et lokalt volum betjener det abonnementet fra filsystemet uten nettverk. Over en deling kan den samme funksjonen degenerere til gjentatte metadatalesinger, fordi varslingsmodellen ikke oppfører seg likt over SMB. Å slå av endringssporing er et rimelig første eksperiment, siden det fjerner en hel klasse forespørsler uten å røre tunnelen.

Prosjektsystemet legger til sin egen trafikk. Innlasting av en løsning teller opp kataloger, leser prosjektfiler og undersøker kanskje SDK-er eller pakker, og hver undersøkelse er en rundtur når stien er ekstern. En løsning med mange prosjekter multipliserer det antallet, og derfor vokser åpningstiden raskere enn filstørrelsene skulle tilsi.

Shell-oppslag som utløper før menyen vises

Windows bidrar med en andre kilde til stopp som ikke har noe med IDE-en å gjøre. Stifinner og shell-utvidelsene dens løser på nytt skrivere, tilknyttede stasjoner og snarveier som ble brukt før, hver gang en kontekstmeny åpnes. Når disse målene ligger på et nettverk tunnelen ikke kan nå, blokkerer hver oppløsning til en tidsavbrudd utløper, og først da tegnes menyen. Derfor kan et høyreklikk henge i sekunder mens selve filen åpnes normalt.

Fjern de døde tilknytningene og skriverkøene, eller behold bare dem som finnes på nettverket du faktisk er på. Samme resonnement dekker alt som løser en sti i bakgrunnen, inkludert lister over nylige filer og festede mapper.

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

Hvorfor en lokal arbeidskopi vinner

Å arbeide direkte på delingen er den dårligste oppsettet for en rediger-bygg-test-løkke, fordi editor, kompilator og versjonskontrollklient hver leser disse eksterne filene separat. Hver av dem betaler sin egen rundtur, og en bygging betaler én gang per fil. En lokal kopi med push gjennom repositoriet erstatter en flom av små kryssinger med én bevisst. Forbindelsen er ikke blitt bedre; antallet kryssinger har kollapset.

Det er en strukturell endring og ikke en tuningøvelse, og det er nettopp derfor det virker når tunnelinnstillinger ikke gjør det. Det gjør også feilmodusen åpenbar: hvis byggingen fortsatt er treg med en lokal kopi, var delingen aldri problemet.

Flytt historikken som ett objekt

Når repositoriet selv må krysse tunnelen, send historikken i ett objekt i stedet for å gå gjennom den. En bundle er én fil og dermed én overføring, mens en checkout som går gjennom tusenvis av løse objekter koster tusenvis av kryssinger. Mercurial og Git støtter begge den formen.

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å treffes, fordi den avgjør hvor mye historikk som reiser. Å bundle alt virker og sløser med forbindelsen, mens bundling fra den siste felles endringen bare flytter det den andre siden mangler.

Mål tre operasjoner før du klandrer båndbredden

Mål tre ting hver for seg: én liten fil åpnet, én katalog oppført, én lagring fullført. Hvis alle tre er trege i forhold til filantallet, er kostnaden rundturer. Hvis én henger mens de andre er fine, mistenker du en tidsavbrudd mot en utilgjengelig ressurs og ikke båndbredde. Noter hvilket nettverk maskinen var på for hver kjøring, fordi en bærbar PC som kobler til en annen profil på nytt kan endre svaret mellom forsøk.

Gjenta så de samme tre mot en lokal kopi av prosjektet. Forskjellen er prisen på delingen, og det er tallet du skal sitere når noen foreslår en raskere forbindelse som løsningen.