Visual Studio traag op een VPN-share: waarom opslaan heen-en-weerritten wordt

Een oplossing die in een seconde opent vanaf een lokale schijf doet er dertig seconden over vanaf een share die via een tunnel bereikbaar is. De tunnel is zelden op zichzelf de oorzaak. Wat verandert, is dat bewerkingen die lokale aanroepen waren synchrone heen-en-weerritten worden, en de editor voert er verschillende uit voordat het venster verschijnt. Het mechanisme hieronder legt uit waarom elk duur is en welke u kunt verwijderen.

Wat de editor doet terwijl een bestand open is

Een editor met het volgen van wijzigingen houdt een abonnement op elk geopend bestand. Een lokaal volume bedient dat abonnement vanuit het bestandssysteem zonder netwerk. Via een share kan dezelfde functie ontaarden in herhaalde metadatalezingen, omdat het notificatiemodel zich over SMB niet hetzelfde gedraagt. Het volgen van wijzigingen uitschakelen is een eerlijk eerste experiment, want het verwijdert een hele klasse verzoeken zonder de tunnel aan te raken.

Het projectsysteem voegt zijn eigen verkeer toe. Het laden van een oplossing inventariseert mappen, leest projectbestanden en controleert mogelijk SDK's of pakketten, en elke controle is een heen-en-weerrit wanneer het pad extern is. Een oplossing met veel projecten vermenigvuldigt dat aantal, waardoor de openingstijd sneller groeit dan de bestandsgrootten zouden suggereren.

Shell-opzoekingen die verlopen voordat het menu verschijnt

Windows draagt een tweede bron van haperingen bij die niets met de IDE te maken heeft. Verkenner en zijn shell-extensies lossen printers, toegewezen stations en eerder gebruikte snelkoppelingen opnieuw op telkens wanneer een contextmenu opent. Wanneer die doelen op een netwerk staan dat de tunnel niet bereikt, blokkeert elke oplossing tot een time-out verloopt, en pas dan wordt het menu getekend. Daarom kan een rechtermuisklik seconden hangen terwijl het bestand zelf normaal opent.

Verwijder de dode toewijzingen en printerwachtrijen, of houd alleen die aan die bestaan op het netwerk waar u werkelijk op zit. Dezelfde redenering geldt voor alles wat op de achtergrond een pad oplost, inclusief lijsten met recente bestanden en vastgemaakte mappen.

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

Waarom een lokale werkkopie wint

Direct op de share werken is de slechtste opzet voor een cyclus van bewerken, bouwen en testen, omdat de editor, de compiler en de versiebeheerclient elk die externe bestanden afzonderlijk lezen. Elk van hen betaalt zijn eigen heen-en-weerrit, en een build betaalt één keer per bestand. Een lokale kopie met pushes via de repository vervangt een vloed van kleine oversteken door één bewuste. De verbinding is niet beter geworden; het aantal oversteken is ingestort.

Dat is een structurele verandering en geen afsteloefering, en precies daarom werkt het wanneer tunnelinstellingen dat niet doen. Het maakt ook de faalmodus duidelijk: als de build met een lokale kopie nog steeds traag is, was de share nooit het probleem.

Verplaats geschiedenis als één object

Wanneer de repository zelf de tunnel moet oversteken, stuur de geschiedenis dan in één object in plaats van die af te lopen. Een bundle is één bestand en dus één overdracht, terwijl een checkout die duizenden losse objecten afloopt duizenden oversteken kost. Mercurial en Git ondersteunen beide die vorm.

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

De basisrevisie is het deel dat je goed moet raken, want die bepaalt hoeveel geschiedenis er reist. Alles bundelen werkt en verspilt de verbinding, terwijl bundelen vanaf de laatste gemeenschappelijke wijziging alleen verplaatst wat de andere kant mist.

Meet drie bewerkingen voordat u de bandbreedte de schuld geeft

Meet drie dingen apart: één klein bestand geopend, één map opgesomd, één opslag voltooid. Als alle drie traag zijn in verhouding tot het aantal bestanden, is de kostenpost heen-en-weerritten. Als er één vastloopt terwijl de andere in orde zijn, verdenk dan een time-out tegen een onbereikbare bron en niet de bandbreedte. Noteer op welk netwerk de machine bij elke run zat, want een laptop die opnieuw verbinding maakt met een ander profiel kan het antwoord tussen pogingen veranderen.

Herhaal daarna dezelfde drie tegen een lokale kopie van het project. Het verschil is de prijs van de share, en dat is het getal dat je moet noemen wanneer iemand een snellere verbinding als oplossing voorstelt.