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 संदर्भ एक बार पढ़ने लायक है, क्योंकि कमांड अपने नाम से कहीं ज़्यादा काम करता है।