Visual Studio je pomalé na VPN zdieľaní: prečo sa ukladanie mení na cesty tam a späť

Riešenie, ktoré sa z lokálneho disku otvorí za sekundu, sa zo zdieľania dostupného cez tunel otvára tridsať sekúnd. Tunel je sám o sebe zriedka príčinou. Mení sa to, že operácie, ktoré boli lokálnymi volaniami, sa stávajú synchrónnymi cestami tam a späť, a editor ich vykoná niekoľko, kým sa okno objaví. Mechanizmus nižšie vysvetľuje, prečo je každá drahá a ktoré môžete odstrániť.

Čo editor robí, kým je súbor otvorený

Editor so sledovaním zmien drží odber na každom otvorenom súbore. Lokálny zväzok obsluhuje ten odber zo súborového systému bez siete. Cez zdieľanie sa tá istá funkcia môže zvrhnúť na opakované čítania metadát, pretože model oznámení sa cez SMB nespráva rovnako. Vypnutie sledovania zmien je férový prvý experiment, keďže odstraňuje celú triedu požiadaviek bez toho, aby sa dotklo tunela.

Projektový systém pridáva vlastnú prevádzku. Načítanie riešenia vypisuje adresáre, číta projektové súbory a môže skúmať SDK alebo balíky, a každé skúmanie je cesta tam a späť, keď je cesta vzdialená. Riešenie s mnohými projektmi tento počet násobí, preto čas otvorenia rastie rýchlejšie, než by naznačovali veľkosti súborov.

Vyhľadávania v shelli, ktoré vypršia pred objavením sa ponuky

Windows pridáva druhý zdroj zaseknutí, ktorý nemá nič spoločné s IDE. Prieskumník a jeho rozšírenia shellu znovu rozlišujú tlačiarne, namapované disky a skratky použité predtým zakaždým, keď sa otvorí kontextová ponuka. Keď tieto ciele ležia v sieti, kam tunel nedosiahne, každé rozlíšenie blokuje, kým nevyprší časový limit, a až potom sa ponuka vykreslí. Preto môže kliknutie pravým tlačidlom visieť sekundy, kým sa samotný súbor otvára normálne.

Odstráňte mŕtve mapovania a tlačové fronty alebo ponechajte iba tie, ktoré existujú v sieti, v ktorej skutočne ste. Rovnaká úvaha platí pre všetko, čo na pozadí rozlišuje cestu, vrátane zoznamov nedávnych súborov a pripnutých priečinkov.

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

Prečo vyhráva lokálna pracovná kópia

Práca priamo na zdieľaní je pre slučku úprava-zostavenie-test najhorším usporiadaním, pretože editor, kompilátor a klient správy verzií čítajú tieto vzdialené súbory každý oddelene. Každý z nich platí svoju vlastnú cestu tam a späť a zostavenie platí raz na súbor. Lokálna kópia s pushovaním cez repozitár nahrádza záplavu drobných prechodov jediným zámerným. Spojenie sa nezlepšilo; počet prechodov sa zrútil.

Je to štrukturálna zmena, nie cvičenie v ladení, a práve preto funguje, keď nastavenia tunela nefungujú. Tiež robí režim zlyhania zrejmým: ak je zostavenie s lokálnou kópiou stále pomalé, zdieľanie nikdy nebolo problémom.

Presuňte históriu ako jeden objekt

Keď musí tunel prekročiť samotný repozitár, pošlite históriu ako jeden objekt namiesto jej prechádzania. Balík je jeden súbor a teda jeden prenos, kým checkout prechádzajúci tisíce voľných objektov stojí tisíce prechodov. Mercurial aj Git podporujú túto formu.

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

Základná revízia je časť, ktorú treba trafiť, pretože rozhoduje, koľko histórie cestuje. Zbaliť všetko funguje a plytvá spojením, kým balenie od poslednej spoločnej zmeny presúva len to, čo druhej strane chýba.

Zmerajte tri operácie, kým obviníte šírku pásma

Zmerajte tri veci oddelene: jeden malý súbor otvorený, jeden adresár vypísaný, jedno uloženie dokončené. Ak sú všetky tri pomalé úmerne počtu súborov, nákladom sú cesty tam a späť. Ak jedna uviazne a ostatné sú v poriadku, podozrievajte časový limit voči nedostupnému zdroju, nie šírku pásma. Poznamenajte, v ktorej sieti bol stroj pri každom behu, pretože notebook, ktorý sa znova pripojí k inému profilu, môže zmeniť odpoveď medzi pokusmi.

Potom zopakujte tie isté tri voči lokálnej kópii projektu. Rozdiel je cena zdieľania, a to je číslo, ktoré treba citovať, keď niekto navrhne rýchlejšie spojenie ako riešenie.