Visual Studio er langsom på en VPN-deling: hvorfor gem bliver rundture

En løsning, der åbner på et sekund fra en lokal disk, tager tredive sekunder fra en deling, der nås gennem en tunnel. Tunnelen er sjældent årsagen i sig selv. Det, der ændrer sig, er, at operationer, som var lokale kald, bliver synkrone rundture, og editoren udfører flere af dem, før vinduet vises. Mekanismen nedenfor forklarer, hvorfor hver enkelt er dyr, og hvilke du kan fjerne.

Hvad editoren gør, mens en fil er åben

En editor med ændringssporing holder et abonnement på hver fil, den har åben. Et lokalt drev betjener det abonnement fra filsystemet uden netværk. Over en deling kan den samme funktion degenerere til gentagne metadata-læsninger, fordi notifikationsmodellen ikke opfører sig ens over SMB. At slå ændringssporing fra er et rimeligt første eksperiment, da det fjerner en hel klasse af anmodninger uden at røre tunnelen.

Projektsystemet tilføjer sin egen trafik. Indlæsning af en løsning opregner mapper, læser projektfiler og undersøger måske SDK'er eller pakker, og hver undersøgelse er en rundtur, når stien er fjern. En løsning med mange projekter ganger det antal, og derfor vokser åbningstiden hurtigere, end filstørrelserne antyder.

Shell-opslag, der udløber, før menuen vises

Windows bidrager med en anden kilde til stop, som intet har med IDE'en at gøre. Stifinder og dens shell-udvidelser opløser igen printere, tilknyttede drev og genveje, der blev brugt før, hver gang en kontekstmenu åbnes. Når disse mål ligger på et netværk, som tunnelen ikke kan nå, blokerer hver opløsning, indtil en timeout udløber, og først da tegnes menuen. Derfor kan et højreklik hænge i sekunder, mens selve filen åbner normalt.

Fjern de døde tilknytninger og printerkøer, eller behold kun dem, der findes på det netværk, du faktisk er på. Den samme ræsonnement dækker alt, der opløser en sti i baggrunden, herunder lister over seneste filer og fastgjorte mapper.

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

Hvorfor en lokal arbejdskopi vinder

At arbejde direkte på delingen er den dårligste opsætning til en rediger-byg-test-løkke, fordi editor, compiler og versionsstyringsklient hver læser disse fjernfiler separat. Hver af dem betaler sin egen rundtur, og et byg betaler én gang per fil. En lokal kopi med push gennem repositoriet erstatter en flod af små krydsninger med én bevidst. Forbindelsen er ikke blevet bedre; antallet af krydsninger er kollapset.

Det er en strukturel ændring og ikke en tuning-øvelse, og det er netop derfor, det virker, når tunnelindstillinger ikke gør. Det gør også fejltilstanden indlysende: hvis bygget stadig er langsomt med en lokal kopi, var delingen aldrig problemet.

Flyt historik som ét objekt

Når repositoriet selv skal krydse tunnelen, send historik i ét objekt i stedet for at gå den igennem. Et bundle er én fil og dermed én overførsel, mens et checkout, der går gennem tusindvis af løse objekter, koster tusindvis af krydsninger. Mercurial og Git understøtter begge den form.

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

Basisrevisionen er den del, der skal rammes, fordi den afgør, hvor meget historik der rejser. At bundle alt virker og spilder forbindelsen, mens bundling fra den sidste fælles ændring kun flytter det, den anden side mangler.

Mål tre operationer, før du bebrejder båndbredden

Mål tre ting hver for sig: én lille fil åbnet, én mappe opregnet, ét gem fuldført. Hvis alle tre er langsomme i forhold til filantallet, er omkostningen rundture. Hvis én hænger, mens de andre er fine, så mistænk en timeout mod en utilgængelig ressource snarere end båndbredde. Notér, hvilket netværk maskinen var på for hver kørsel, fordi en bærbar computer, der genopretter forbindelse til en anden profil, kan ændre svaret mellem forsøg.

Gentag så de samme tre mod en lokal kopi af projektet. Forskellen er prisen for delingen, og det er det tal, du skal citere, når nogen foreslår en hurtigere forbindelse som løsningen.