इंजीनियरिंग

इंजीनियरिंग

Mythex कैसे बनता और चलता है, जिसमें यह भी कि क्या टूटा और हमने उसे कैसे ठीक किया।

• विफल रीपब्लिश कभी चालू बैकएंड को नहीं मिटाता — एक विफल रीपब्लिश किसी ऐप की लाइव API को मिटा सकता था, या उसका टूटा हुआ नया वर्शन चालू छोड़ सकता था। Mythex में गलत हुए पब्लिश को वापस करने के तरीके में तीन सुधार।
• अलर्ट एक बार चलें, हर सर्वर पर एक बार नहीं — एक दिन में एक बार जाने वाला अलर्ट एक ही दोपहर में पाँच बार हम तक पहुँचा। दो सर्वरों और एक डिप्लॉय के साथ इन-मेमोरी डेडुप क्यों टूटता है, और साझा स्टेट ने इसे कैसे ठीक किया।
• किसी को इंतज़ार कराए बिना बड़े वर्कस्पेस पर जाना — 2 GB पर जाने के बाद हमारे एक-चौथाई वर्कस्पेस 1 GB पर अटके रहे। हमारे पहले सुधार ने एक व्यक्ति को सात मिनट इंतज़ार कराया। हमने क्या बदला, और फिर से क्या बदला।
• डेटाबेस की बिलिंग उनके असली इस्तेमाल के हिसाब से — हम हर ऐप के डेटाबेस की लागत का अनुमान लगाते थे, और वह अनुमान दोनों तरफ़ से गलत था। अब हर डेटाबेस की बिलिंग मापे गए उपयोग से होती है, घंटे-दर-घंटे।
• पब्लिश के ठीक बाद क्रैश होने वाले ऐप्स को पकड़ना — तीन पब्लिश हमारे हेल्थ चेक से पास हो गए, जबकि उनकी API हर बूट के कुछ सेकंड बाद क्रैश हो रही थी। कारण: क्रैश गिनना एक ऐसी सूची में, जो पाँच एंट्री तक सीमित है।
• इमेज-भारी एजेंट टर्न को मेमोरी के भीतर रखना — एक एजेंट टर्न catalogue scans देखते हुए 952 MB पर मेमोरी से बाहर हो गया। तीन अलग कारण, हर एक इमेज को ज़रूरत से ज़्यादा देर रोके हुए, और हमने उन्हें कैसे ठीक किया।
• लंबे एजेंट टर्न को context window के भीतर रखना — हमारे sub-agents इतने बढ़ जाते थे कि मॉडल उन्हें मना कर देता था, जगह बचाने को जल्दी रुक जाते थे, और रूसी में tokens गलत गिनते थे। तीन फ़िक्स जिनसे लंबा AI काम पूरा होता है।
• जब फ़ोन सो जाए तब भी चैट चालू रखना — फ़ोन सोते हैं, tab बदलते हैं और build के बीच network छोड़ देते हैं। दो bugs ने चैट को अटकाया या बाद में आधा जवाब दिखाया। हमने दोनों कैसे खोजे और ठीक किए।
• एक भारी चैट हमारा API कैसे गिरा सकती थी — 28 सितंबर को हमारे दोनों API सर्वर एक साथ मेमोरी से बाहर हो गए। पहला फ़िक्स ज़्यादा मेमोरी थी; असली फ़िक्स था चैट का इतिहास आकार से लोड करना, गिनती से नहीं।
• Publish दो बार दबाने पर अब एक ही बार पब्लिश होता है — एक ही ऐप के लिए तीन publish requests 84ms के अंतर से पहुँचीं और हर एक ने पूरा deploy चलाया। हमने डेटाबेस को तय करने दिया कि कौन पब्लिश करेगा, और बाकियों को सच बताया।
• अपनी ही साइट ठीक करने से मिले SEO सबक — दोहरा FAQ मार्कअप, Google में गलत थंबनेल, बेकार टेम्पलेट पेज, और एक पाथ जिसे हमारा एज ब्लॉक कर रहा था: mythex.ai पर जो मिला और जो ठीक किया।
• स्टैटिक साइट्स अब रीपब्लिश होते समय भी चालू रहती हैं — पहले रीपब्लिश में नया बिल्ड अपलोड होने से पहले साइट खाली हो जाती थी। अब नया बिल्ड लगने तक पुरानी साइट चलती रहती है, और बदलाव सेकंडों में दिखते हैं।
• प्रोग्रेस लेबल में छिपा आउट-ऑफ़-मेमोरी क्रैश — हमारा AI एजेंट एक बड़ी फ़ाइल लिखते समय मेमोरी खत्म होने से क्रैश हो गया। कारण न मॉडल था न समानांतर सब-एजेंट, बल्कि एक स्टेटस लेबल था जो 41,000 बार दोबारा भेजा गया।
• गायब स्वैप फ़ाइल जिसने हमारे सर्वर जमा दिए — एक प्रोडक्शन सर्वर क्रैश हुए बिना जवाब देना बंद कर गया: कोई आउट-ऑफ़-मेमोरी किल नहीं, बस बिना स्वैप वाली मशीन पर पेज-कैश थ्रैश। क्या हुआ और हमने क्या बदला।
• डेटाबेस को बिना मृत कनेक्शन के जगाना — नींद से जागता पब्लिश किया गया ऐप अपने पहले अनुरोध को 10–12 सेकंड तक रोके रखता था, उन डेटाबेस कनेक्शन पर जो सोते समय मर चुके थे। हमने इसे 2.3 सेकंड तक कैसे लाया।
• हम अपनी ही सेवाओं पर रेट लिमिट लगा रहे थे — हमारे API की प्रति-पता रेट लिमिट ने हमारी अपनी सेवाओं को एक व्यस्त व्यक्ति की तरह माना, और प्रोडक्शन में उन्हें 429 मिलने लगे। हमने इसे कैसे खोजा और ठीक किया।
• हमने Mythex के सर्वर ARM पर क्यों ले गए — भारी काम प्रति-प्रोजेक्ट सैंडबॉक्स में चले जाने के बाद हमारे सर्वर अपनी मेमोरी का एक-तिहाई इस्तेमाल कर रहे थे। छोटी ARM मशीनों ने मासिक सर्वर बिल लगभग 30% घटाया। यह कैसे हुआ।
• हम डिप्लॉय को शून्य 502 एरर तक कैसे लाए — हमारे डिप्लॉय से दौड़ लगाता एक वॉचडॉग, और एक लोड बैलेंसर जिसने बहुत देर से ध्यान दिया: हमने दोनों को कैसे खोजा, ठीक किया, और डिप्लॉय में 10 502 से शून्य तक मापा।