किसी को इंतज़ार कराए बिना बड़े वर्कस्पेस पर जाना

हर Mythex प्रोजेक्ट को अपना वर्कस्पेस मिलता है: एक छोटा क्लाउड कंप्यूटर, जहाँ एजेंट कोड लिखता है और आपके ऐप का प्रिव्यू चलता है। हमने नए वर्कस्पेस की मेमोरी 1 GB से बढ़ाकर 2 GB कर दी थी, लेकिन पुराने वर्कस्पेस 1 GB पर ही रहे; जिस दिन हमने जाँचा, उनमें लगभग एक-चौथाई ऐसे थे। हमारे पहले सुधार ने किसी प्रोजेक्ट को अगली बार खुलने पर बड़े वर्कस्पेस में ले जाने की कोशिश की। प्रोडक्शन में पहले ही दिन उससे एक व्यक्ति को सात मिनट इंतज़ार करना पड़ा। हमने उस पर एक सख्त समय-सीमा लगाई, फिर प्रोजेक्ट खोलने से यह कदम पूरी तरह हटा दिया।

पुराने वर्कस्पेस छोटे क्यों रहे

हमारा सैंडबॉक्स प्रोवाइडर वर्कस्पेस का आकार उसके बनने के समय तय करता है, और हर पॉज़ और रिज़्यूम में उसे बनाए रखता है। टेम्पलेट बदलने से, यानी वह रेसिपी जिससे नए वर्कस्पेस बनते हैं, केवल बदलाव के बाद बने वर्कस्पेस प्रभावित होते हैं। जो पहले से मौजूद हैं, उनका आकार कोई नहीं बदलता।

यह मायने रखता था। छोटे वर्कस्पेस में से एक, उसके प्रिव्यू के शुरू होने के दौरान git push में मेमोरी खत्म हो गई और 11 मिनट तक जवाब देना बंद कर दिया। इसकी वजह से एक पब्लिश विफल हो गया।

पहला प्रयास: जागने पर प्रोजेक्ट को ले जाना

जब कोई उपयोग नहीं कर रहा होता, तब वर्कस्पेस रुक जाते हैं, और प्रोजेक्ट खुलने पर जाग जाते हैं। जागना प्रोजेक्ट को ले जाने का सही समय लगा, क्योंकि उसमें अभी कोई काम नहीं कर रहा होता।

स्थानांतरण इस तरह काम करता था:

1. आकार जाँचें। अगर वर्कस्पेस 2 GB से छोटा है, तो उसे ले जाएँ। अगर उसका आकार पता नहीं, तो कुछ न करें।
2. पब्लिश में खलल न डालें। पब्लिश वर्कस्पेस की फ़ाइलें पढ़ता है, इसलिए अगर कोई चल रहा हो, तो स्थानांतरण छोड़ दें।
3. प्रोजेक्ट को पैक करें। प्रोजेक्ट का सब कुछ आर्काइव करें, जिसमें उसकी git हिस्ट्री शामिल है (यानी प्रोजेक्ट के हर चेकपॉइंट) और ऐप की अपनी .env फ़ाइल भी, जो मालिक की है। लेकिन इंस्टॉल की हुई डिपेंडेंसी (node_modules) छोड़ दें, क्योंकि उन्हें दोबारा इंस्टॉल किया जा सकता है।
4. सीधे कॉपी करें। पुराने वर्कस्पेस से आर्काइव को एक नए 2 GB वर्कस्पेस में स्ट्रीम करें, ताकि वह कभी हमारे अपने सर्वर की मेमोरी में न समाए।
5. बदलने से पहले तुलना करें। दोनों वर्कस्पेस में फ़ाइलें गिनें, नवीनतम चेकपॉइंट पढ़ें, और चेकपॉइंट गिनें। तभी बदलें जब तीनों मेल खाएँ।
6. किसी भी विफलता पर पुराना रखें। कोई भी एरर या बेमेल नए वर्कस्पेस को हटा देता है और प्रोजेक्ट पहले की तरह पुराने वर्कस्पेस में खुलता है।

तुलना की एक बारीकी उसके दिखने से ज़्यादा मायने रखती थी। यह जाँच एडमिनिस्ट्रेटर खाते से चलती है, और git किसी ऐसी repository को पढ़ने से इनकार करता है जो किसी दूसरे यूज़र की हो। दोनों तरफ़ से कुछ भी नहीं छपा, और "कुछ नहीं" का "कुछ नहीं" से मिलान हो गया, इसलिए जाँच बिना किसी हिस्ट्री की तुलना किए पास हो गई। हमने git को डायरेक्टरी पर भरोसा करने के लिए कहा, और एक टेस्ट जोड़ा ताकि यह फिर से न खिसके।

पहले ही दिन क्या गलत हुआ

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

ऐसा स्थानांतरण जो किसी को अपना प्रोजेक्ट खोलते समय इंतज़ार कराए, बुरा सौदा है। जागने पर इसे करने का पूरा मकसद यह था कि किसी को पता न चले।

दूसरा प्रयास: सख्त बजट

उसी दिन हमने चार चीज़ें बदलीं:

• पूरे स्थानांतरण के लिए एक मिनट। हर कदम, यानी आकार जाँचना, पैक करना, नया वर्कस्पेस बनाना, कॉपी करना, खोलना और तुलना करना, एक ही 60 सेकंड के बजट को साझा करता है। जब वह खत्म होता है, प्रोजेक्ट पुराने वर्कस्पेस में खुलता है।
• केवल इंतज़ार नहीं, काम भी रोकें। हमारी ओर से हार मान लेना काफ़ी नहीं है, अगर आर्काइव करने का काम उस वर्कस्पेस में अब भी चल रहा है जिसे मालिक इस्तेमाल करने वाला है। अब हर आर्काइव कमांड बजट खत्म होने से ठीक पहले वर्कस्पेस के भीतर ही बंद कर दी जाती है। अगर नया वर्कस्पेस तब पहुँचता है जब हम हार मान चुके हैं, तो उसे हटा दिया जाता है।
• मालिक को सफ़ाई का इंतज़ार न कराएँ। अस्थायी आर्काइव हटाना अब बैकग्राउंड में होता है।
• हर खुलने पर फिर कोशिश न करें। जो प्रोजेक्ट ले नहीं जाया जा सका, उसे 24 घंटे के लिए छोड़ दिया जाता है, ताकि एक विफलता दिन में अधिकतम एक देरी लाए, न कि हर खुलने पर एक।

तीसरा प्रयास: इसे जागने से बाहर निकालें

इससे सबसे खराब स्थिति एक मिनट हो गई। लेकिन एक मिनट भी एक मिनट है, और हमें समझ आया कि स्थानांतरण को किसी के रास्ते में होने की ज़रूरत ही नहीं थी।

अब 1 GB पर कोई वर्कस्पेस नहीं बनता। तो यह कोई चलती रहने वाली प्रक्रिया नहीं है; यह वर्कस्पेस की तय सूची वाला एक बार का काम है। इसे जागने के भीतर रखने का मतलब था कि हर धीमे स्थानांतरण की कीमत एक असली व्यक्ति चुकाता था, और हमें केवल तभी पता चलता कि कोई वर्कस्पेस नहीं खिसका, जब कोई उसके लिए इंतज़ार कर चुका होता।

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

हमने इससे क्या सीखा

• आकार बदलना हमेशा संभव नहीं होता। जब प्लेटफ़ॉर्म बनने के समय आकार तय कर देता है, तो डिफ़ॉल्ट बढ़ाना केवल नई चीज़ों की मदद करता है। पुरानी चीज़ों की योजना अलग से बनाएँ।
• "अभी किसी ने इस्तेमाल नहीं किया" का मतलब अब भी कोई इंतज़ार कर रहा है। किसी प्रोडक्ट में घुसने के रास्ते पर किया गया काम वह काम है जिसे एक व्यक्ति देखता है।
• उपयोगकर्ता के रास्ते में किसी भी चीज़ पर बजट लगाएँ, और बजट खत्म होने पर काम रोकें। हमारी ओर से टाइमआउट होना, जबकि कोई कमांड कहीं और चलती रहे, समस्या को केवल इधर-उधर करता है।
• एक बार का माइग्रेशन एक बार के काम में होना चाहिए। उसे रोज़ की क्रियाओं के भीतर छिपाने से उसे लिखना सस्ता और चलाना महँगा हो जाता है।
• अपनी सुरक्षा-जाँचों का टेस्ट करें। जो तुलना कुछ तुलना ही नहीं करती, वह बिल्कुल उस तुलना जैसी दिखती है जो पास हो गई।

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