Visual Studio je pomalé na VPN sdílení: proč se ukládání mění v cesty tam a zpět

Řešení, které se z místního disku otevře za sekundu, se ze sdílené složky dostupné přes tunel otevírá třicet sekund. Tunel sám o sobě je zřídka příčinou. Mění se to, že operace, které byly místními voláními, se stávají synchronními cestami tam a zpět, a editor jich několik provede, než se okno objeví. Mechanismus níže vysvětluje, proč je každá drahá a které můžete odstranit.

Co editor dělá, dokud je soubor otevřený

Editor se sledováním změn drží odběr na každém otevřeném souboru. Místní svazek tento odběr obsluhuje ze souborového systému bez sítě. Přes sdílenou složku se stejná funkce může zhoršit v opakovaná čtení metadat, protože model oznámení se přes SMB nechová stejně. Vypnutí sledování změn je rozumný první experiment, protože odstraní celou třídu požadavků, aniž by se dotklo tunelu.

Projektový systém přidává vlastní provoz. Načtení řešení vypisuje adresáře, čte projektové soubory a může zkoumat SDK nebo balíčky, a každé zkoumání je cesta tam a zpět, když je cesta vzdálená. Řešení s mnoha projekty tento počet násobí, a proto doba otevření roste rychleji, než by naznačovaly velikosti souborů.

Vyhledávání v shellu, která vyprší dřív, než se objeví nabídka

Windows přidává druhý zdroj zaseknutí, který s IDE nemá nic společného. Průzkumník a jeho rozšíření shellu znovu rozlišují tiskárny, namapované disky a zástupce použité dříve pokaždé, když se otevře kontextová nabídka. Když tyto cíle leží v síti, kam tunel nedosáhne, každé rozlišení blokuje, dokud nevyprší časový limit, a teprve pak se nabídka vykreslí. Proto může kliknutí pravým tlačítkem viset sekundy, zatímco soubor samotný se otevírá normálně.

Odstraňte mrtvá mapování a tiskové fronty, nebo ponechte jen ta, která existují v síti, ve které skutečně jste. Stejná úvaha platí pro cokoli, co na pozadí rozlišuje cestu, včetně seznamů nedávných souborů a připnutých složek.

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

Proč vyhrává místní pracovní kopie

Práce přímo na sdílené složce je pro smyčku úprava-sestavení-test nejhorší uspořádání, protože editor, kompilátor i klient správy verzí čtou tyto vzdálené soubory odděleně. Každý platí svou vlastní cestu tam a zpět a sestavení platí jednou za soubor. Místní kopie s pushováním přes repozitář nahrazuje záplavu drobných přechodů jediným záměrným. Spojení se nezlepšilo; počet přechodů se zhroutil.

To je strukturální změna, nikoli cvičení v ladění, a právě proto funguje, když nastavení tunelu nefungují. Také činí režim selhání zřejmým: pokud je sestavení s místní kopií stále pomalé, sdílená složka nikdy nebyla problém.

Přesuňte historii jako jeden objekt

Když musí tunel překročit samotný repozitář, pošlete historii jako jeden objekt místo jejího procházení. Balík je jediný soubor a tedy jediný přenos, zatímco checkout procházející tisíce volných objektů stojí tisíce přechodů. Mercurial i Git tuto podobu podporují.

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

Základní revize je část, kterou je třeba trefit, protože rozhoduje, kolik historie cestuje. Zabalit vše funguje a plýtvá spojením, zatímco balení od poslední společné změny přesouvá jen to, co druhé straně chybí.

Změřte tři operace, než obviníte šířku pásma

Změřte tři věci odděleně: jeden malý soubor otevřen, jeden adresář vypsán, jedno uložení dokončeno. Pokud jsou všechny tři pomalé úměrně počtu souborů, cena jsou cesty tam a zpět. Pokud jedna uvízne a ostatní jsou v pořádku, podezřívejte časový limit vůči nedostupnému zdroji, ne šířku pásma. Poznamenejte, v které síti byl stroj při každém běhu, protože notebook, který se znovu připojí k jinému profilu, může odpověď mezi pokusy změnit.

Potom zopakujte totéž proti místní kopii projektu. Rozdíl je cena sdílené složky a to je číslo, které je třeba citovat, když někdo navrhne rychlejší spojení jako řešení.