VPN शेयर पर Visual Studio धीमा: सेव क्यों राउंड ट्रिप में बदल जाता है

स्थानीय डिस्क से एक सेकंड में खुलने वाला समाधान टनल से पहुँचे शेयर से खुलने में तीस सेकंड लेता है। टनल अपने आप में शायद ही कभी कारण होता है। जो बदलता है वह यह है कि जो ऑपरेशन स्थानीय कॉल थे वे समकालिक राउंड ट्रिप बन जाते हैं, और विंडो दिखने से पहले एडिटर उनमें से कई करता है। नीचे की प्रक्रिया बताती है कि हर एक महँगा क्यों है और किन्हें आप हटा सकते हैं।

फ़ाइल खुली रहने पर एडिटर क्या करता है

बदलाव ट्रैकिंग वाला एडिटर हर खुली फ़ाइल पर एक सदस्यता रखता है। स्थानीय वॉल्यूम वह सदस्यता नेटवर्क के बिना फ़ाइल सिस्टम से पूरी करता है। शेयर पर वही सुविधा बार-बार मेटाडेटा पढ़ने में बदल सकती है, क्योंकि अधिसूचना मॉडल 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

आधार संशोधन वह हिस्सा है जिसे सही पाना है, क्योंकि यह तय करता है कि कितना इतिहास यात्रा करेगा। सब कुछ बंडल करना काम करता है और लिंक बर्बाद करता है, जबकि अंतिम साझा बदलाव से बंडल करना केवल वही ले जाता है जो दूसरी ओर के पास नहीं है।

बैंडविड्थ को दोष देने से पहले तीन ऑपरेशन मापें

तीन चीज़ें अलग-अलग मापें: एक छोटी फ़ाइल खुली, एक डायरेक्टरी सूचीबद्ध, एक सेव पूर्ण। अगर तीनों फ़ाइल संख्या के अनुपात में धीमे हैं, तो लागत राउंड ट्रिप है। अगर एक अटके और बाकी ठीक हों, तो बैंडविड्थ नहीं बल्कि अगम्य संसाधन के प्रति समय-सीमा का संदेह करें। हर रन में मशीन किस नेटवर्क पर थी यह नोट करें, क्योंकि दूसरे प्रोफ़ाइल से फिर जुड़ने वाला लैपटॉप प्रयासों के बीच उत्तर बदल सकता है।

फिर प्रोजेक्ट की स्थानीय प्रति के सामने वही तीन दोहराएँ। अंतर शेयर की कीमत है, और यही वह संख्या है जो तब उद्धृत करनी चाहिए जब कोई तेज़ लिंक को समाधान बताए।