Visual Studio е бавен върху VPN споделяне: защо запазването става кръгови заявки
Редактирането през споделяне превръща запазването, менютата и проследяването на промени в кръгови заявки. Преместете работното копие локално и пренасяйте историята като един обект, вместо да я обхождате.
Решение, което се отваря за секунда от локален диск, се отваря за тридесет секунди от споделяне, достигнато през тунел. Тунелът рядко е причината сам по себе си. Това, което се променя, е, че операции, които бяха локални извиквания, стават синхронни кръгови заявки, и редакторът изпълнява няколко от тях, преди прозорецът да се появи. Механизмът по-долу обяснява защо всяка е скъпа и кои можете да премахнете.
Какво прави редакторът, докато файлът е отворен
Редактор с проследяване на промени поддържа абонамент за всеки отворен файл. Локалният том обслужва този абонамент от файловата система без мрежа. През споделяне същата функция може да се изроди в повтарящи се четения на метаданни, защото моделът на уведомяване не работи по същия начин през SMB. Изключването на проследяването на промени е честен първи експеримент, тъй като премахва цял клас заявки, без да пипа тунела.
Проектната система добавя собствен трафик. Зареждането на решение изброява директории, чете проектни файлове и може да проверява за SDK или пакети, а всяка проверка е кръгова заявка, когато пътят е отдалечен. Решение с много проекти умножава този брой, затова времето за отваряне расте по-бързо, отколкото размерите на файловете подсказват.
Търсения на обвивката, които изтичат, преди менюто да се появи
Windows добавя втори източник на забавяния, който няма нищо общо с IDE. Explorer и неговите разширения на обвивката разрешават наново принтери, свързани дискове и преки пътища, използвани преди, всеки път, когато се отвори контекстно меню. Когато тези цели са в мрежа, до която тунелът не може да достигне, всяко разрешаване блокира, докато изтече таймаут, и едва тогава менюто се изчертава. Затова щракване с десния бутон може да виси секунди, докато самият файл се отваря нормално.
Премахнете мъртвите връзки и опашките за печат или задръжте само тези, които съществуват в мрежата, в която наистина сте. Същата логика покрива всичко, което разрешава път във фонов режим, включително списъци с последни файлове и закачени папки.
net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }
Защо локалното работно копие печели
Работата директно върху споделянето е най-лошата настройка за цикъл редактиране-компилиране-тест, защото редакторът, компилаторът и клиентът за контрол на версиите четат тези отдалечени файлове поотделно. Всеки от тях плаща своята кръгова заявка, а компилацията плаща веднъж на файл. Локално копие с изтласкване през хранилището заменя потока от дребни пресичания с едно умишлено. Връзката не се е подобрила; броят на пресичанията се е сринал.
Това е структурна промяна, а не упражнение по настройка, и точно затова работи, когато настройките на тунела не работят. Тя също прави режима на отказ очевиден: ако компилацията е все още бавна с локално копие, споделянето никога не е било проблемът.
Преместете историята като един обект
Когато самото хранилище трябва да прекоси тунела, изпращайте историята като един обект, вместо да я обхождате. Пакетът е един файл и следователно един трансфер, докато checkout, който обхожда хиляди разхвърляни обекта, струва хиляди пресичания. Mercurial и Git поддържат тази форма.
hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo
Базовата ревизия е частта, която трябва да улучите, защото тя решава колко история пътува. Пакетирането на всичко работи и прахосва връзката, докато пакетирането от последната обща промяна пренася само това, което другата страна няма.
Измерете три операции, преди да обвинявате честотната лента
Измерете три неща поотделно: един малък файл отворен, една директория изброена, едно запазване завършено. Ако и трите са бавни пропорционално на броя файлове, цената са кръговите заявки. Ако едно забива, докато другите са наред, подозирайте таймаут към недостъпен ресурс, а не честотната лента. Отбележете в коя мрежа е била машината при всеки пуск, защото лаптоп, който се свързва отново с друг профил, може да промени отговора между опитите.
След това повторете същите три срещу локално копие на проекта. Разликата е цената на споделянето и това е числото, което да цитирате, когато някой предложи по-бърза връзка като решение.