Visual Studio je počasen na VPN delitvi: zakaj shranjevanje postane potovanja tja in nazaj

Rešitev, ki se z lokalnega diska odpre v sekundi, se z delitve, dosegljive prek tunela, odpira trideset sekund. Tunel je sam po sebi redko vzrok. Spremeni se to, da operacije, ki so bile lokalni klici, postanejo sinhrone poti tja in nazaj, in urejevalnik jih izvede več, preden se okno prikaže. Spodnji mehanizem pojasnjuje, zakaj je vsaka draga in katere lahko odstranite.

Kaj urejevalnik počne, dokler je datoteka odprta

Urejevalnik s sledenjem sprememb drži naročnino na vsaki odprti datoteki. Lokalni zvezek to naročnino streže iz datotečnega sistema brez omrežja. Prek delitve se ista funkcija lahko poslabša v ponavljajoče se branje metapodatkov, ker se model obvestil prek SMB ne obnaša enako. Izklop sledenja sprememb je pošten prvi poskus, saj odstrani cel razred zahtev, ne da bi se dotaknil tunela.

Projektni sistem doda svoj promet. Nalaganje rešitve našteje mape, bere projektne datoteke in lahko preverja SDK ali pakete, in vsako preverjanje je pot tja in nazaj, ko je pot oddaljena. Rešitev s številnimi projekti to število pomnoži, zato se čas odpiranja povečuje hitreje, kot bi nakazovale velikosti datotek.

Iskanja v lupini, ki potečejo, preden se prikaže meni

Windows doda drug vir zastojev, ki nima nič skupnega z IDE. Raziskovalec in njegove razširitve lupine znova razrešujejo tiskalnike, preslikane pogone in prej uporabljene bližnjice vsakič, ko se odpre kontekstni meni. Ko so te tarče v omrežju, do katerega tunel ne seže, vsaka razrešitev blokira, dokler ne poteče časovna omejitev, in šele takrat se meni nariše. Zato lahko desni klik visi več sekund, medtem ko se datoteka sama odpira normalno.

Odstranite mrtve preslikave in tiskalniške vrste ali obdržite le tiste, ki obstajajo v omrežju, v katerem ste v resnici. Ista logika velja za vse, kar v ozadju razrešuje pot, vključno s seznami nedavnih datotek in pripetimi mapami.

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

Zakaj zmaga lokalna delovna kopija

Delo neposredno na delitvi je najslabša nastavitev za zanko urejanja, gradnje in testiranja, ker urejevalnik, prevajalnik in odjemalec za nadzor različic vsak posebej berejo te oddaljene datoteke. Vsak od njih plača svojo pot tja in nazaj, gradnja pa plača enkrat na datoteko. Lokalna kopija s potiskanjem skozi shrambo nadomesti poplavo majhnih prehodov z enim namernim. Povezava se ni izboljšala; število prehodov se je zrušilo.

To je strukturna sprememba in ne vaja v uglaševanju, in prav zato deluje, ko nastavitve tunela ne delujejo. Prav tako naredi način okvare očiten: če je gradnja z lokalno kopijo še vedno počasna, delitev nikoli ni bila problem.

Premaknite zgodovino kot en objekt

Ko mora sam repozitorij prestopiti tunel, pošljite zgodovino v enem objektu, namesto da bi jo prehodili. Paket je ena datoteka in zato en prenos, medtem ko checkout, ki prehodi tisoče prostih objektov, stane tisoče prehodov. Mercurial in Git oba podpirata to obliko.

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

Osnovna revizija je del, ki ga je treba zadeti, ker odloči, koliko zgodovine potuje. Pakiranje vsega deluje in zapravlja povezavo, medtem ko pakiranje od zadnje skupne spremembe premakne le tisto, kar drugi strani manjka.

Izmerite tri operacije, preden krivite pasovno širino

Izmerite tri stvari ločeno: ena majhna datoteka odprta, en imenik naštet, eno shranjevanje dokončano. Če so vse tri počasne sorazmerno s številom datotek, so strošek poti tja in nazaj. Če se ena zatakne, druge pa so v redu, sumite na časovno omejitev proti nedosegljivemu viru in ne na pasovno širino. Zapišite, v katerem omrežju je bil stroj pri vsakem zagonu, ker prenosnik, ki se znova poveže z drugim profilom, lahko spremeni odgovor med poskusi.

Nato ponovite iste tri proti lokalni kopiji projekta. Razlika je cena delitve, in to je število, ki ga je treba navesti, ko nekdo predlaga hitrejšo povezavo kot rešitev.