VPN वर SSHFS वर git status हळू चालतो: काम हलवा

200 MB फाइल कॉपी करा आणि ती उडते. त्याच डिरेक्टरीत git status चालवा आणि प्रतीक्षा इतकी लांब असते की दुसऱ्या कामाकडे लक्ष जाते. ही दोन निरीक्षणे विरोधाभासी नाहीत, कारण मोठ्या प्रमाणातील हस्तांतरण थ्रूपुट मोजते तर Git प्रति सेकंद किती लहान फाइलसिस्टम प्रश्न विचारू शकतो हे मोजते, आणि माउंट केलेले दूरचे झाड प्रत्येक प्रश्नाची एक फेरी करते. VPN ट्यून केल्याने चुकीच्या आकाराचे काम सुधारणार नाही.

status चुकीचा मापदंड का आहे

Git ला अनेक फाइलींबद्दल माहीत असावे लागते: कोणती बदलली, कोणती ट्रॅक झाली नाही आणि कॅश केलेला इंडेक्स डेटा अजूनही डिस्कवरील डेटाशी जुळतो का. SSHFS वरून यातील प्रत्येक निरीक्षण नेटवर्क क्रिया असू शकते. येथे कामाचे एकक फाइलींची संख्या आहे, मेगाबाइट नाही.

म्हणूनच क्लोननंतरचा पहिला status हळू असतो, आणि म्हणूनच बिल्ड आउटपुटने भरलेल्या झाडात पुढचे आणखी हळू असू शकतात. ट्रॅक न झालेल्या फाइलींचे स्कॅनिंग तुम्हाला नको असलेल्या डिरेक्टरींमधून जाते, आणि प्रत्येक पाऊल लिंकवरून आणखी एक विनंती आहे. 40 ms च्या मार्गावर काही हजार नोंदींचे झाड काही हजार फेऱ्यांमध्ये बदलते. हा हिशोब पडताळण्यासाठी पॅकेट कॅप्चरची गरज नाही.

डाउनलोड मापदंड सांगतो लिंक ठीक आहे; हजार लहान वाचन आज दुपारी पूर्ण होतील का याबद्दल तो काहीही सांगत नाही.

कामाचे झाड हलवा, ट्यूनिंग नॉब नाही

स्थानिक क्लोन कामाचे झाड, इंडेक्स आणि Git क्रिया एकाच मशीनवर ठेवतो. मग pull एक दिसणारे नेटवर्क पाऊल बनते, प्रत्येक फाइल तपासणी नाही.

हे तेव्हा योग्य असते जेव्हा विकसक आवश्यक स्रोत स्थानिक ठेवू शकतो, आणि बहुतेक वेळा तसेच असते. हे commit आणि डिप्लॉयमेंटमधील सीमा देखील तीव्र करते, कारण स्थानिक फाइल संपादित केल्याने आता चालू असलेली दूरची सेवा अपघाताने बदलत नाही; बदल बाकीच्यांसारखा पुश आणि डिप्लॉय करावा लागतो. किंमत ही आहे की कोड दोन ठिकाणी असतो, म्हणून कोणती प्रत अधिकृत आहे आणि सर्व्हरवरील तातडीची दुरुस्ती कशी रेपॉझिटरीत परत येते हे ठरवा. तो संवाद जो कोणी चालवू इच्छित नाही अशा status कमांडपेक्षा स्वस्त आहे.

जर कार्यक्षेत्र दूरच राहावे लागले, तर तिथेच Git चालवा

कधीकधी कार्यक्षेत्र हलवता येत नाही: बिल्डला ते वातावरण लागते, डेटा खूप मोठा आहे, किंवा धोरण स्रोत होस्टवर ठेवते. तेव्हा फाइलींच्या शेजारीच Git आणि संबंधित विकास साधने चालवा, मंजूर दूरच्या शेल किंवा दूरच्या-विकास वातावरणाद्वारे. एडिटर लॅपटॉपवर राहू शकतो, त्याचा बॅकएंड कामाच्या झाडाच्या शेजारी काम करत असताना.

मग महाग क्रिया दूरच्या होस्टवर स्थानिकरीत्या होतात, आणि नेटवर्क हजारो stat कॉलऐवजी एडिटरचा रहदारी वाहते. हा स्थानिक क्लोनसारखाच उपाय आहे, स्थलांतर नाही, डिप्लॉयमेंट निवड म्हणून मांडलेला.

सिंक मालकांसह कार्यप्रवाह आहे, कॅश नाही

सिंक केलेले कार्यक्षेत्र पुनरावृत्तीची दूरची वाचन कमी करू शकते, पण ते पारदर्शक कॅश नाही. प्रत्येक बदलासाठी मालक, संघर्षांसाठी नियम आणि दोन्ही बाजू आपली असे मानणाऱ्या व्युत्पन्न फाइलींबद्दल करार लागतो. त्या नियमांशिवाय ही व्यवस्था सोयीऐवजी मतभेद निर्माण करते.

त्यांशिवाय दुतर्फा सिंक करणारा सोडवलेल्या समस्येपेक्षा वेगळी समस्या निर्माण करतो, सामान्यतः अशी विलीन जी कोणी कोणाला देऊ शकत नाही. एकाच सामायिक कामाच्या झाडावर दोन Git प्रक्रिया चालवणे टाळा, जर त्या कशा समन्वयित होतात हे तुम्हाला समजत नसेल.

मग ट्यून करा, आणि SSH समजूतदार ठेवा

व्यवस्था बरोबर झाल्यावर दोन सेटिंग्ज Git ला किती फाइलींबद्दल विचारावे लागेल ते बदलतात: status.showUntrackedFiles आणि core.untrackedCache मागील ट्रॅक न झालेला कॅश. दोन्हीपैकी कोणीही 40 ms वर प्रत्येक प्रश्नाचा खर्च बदलत नाही; ते फक्त प्रश्नांची संख्या बदलतात. फेऱ्या स्थानिक झाल्यावरच नॉब फिरवा.

एक मोठी फाइल कॉपी करणाऱ्या मापदंडावरून विचार करण्याऐवजी तुम्हाला त्रास देणाऱ्या कमांडचा वेळ मोजा, आणि समर्थित SSH एन्क्रिप्शनला असेच ठेवा. जुने सायफर फेरी लहान करत नाही; ते पहिल्यापेक्षा जास्त टिकणारी दुसरी समस्या जोडते. git status संदर्भ एकदा वाचण्यासारखा आहे, कारण कमांड त्याच्या नावाने सुचवले त्यापेक्षा खूप जास्त काम करते.