Wrk Latency के गलत वितरण का विश्लेषण

wrk एक शानदार HTTP स्ट्रेस टेस्टिंग टूल है जो ओपन सोर्स प्रोजेक्ट्स Redis, NGINX, Node.js और LuaJIT पर बनाया गया है, जो इनकी इवेंट-ड्रिवन, HTTP पार्सिंग, हाई परफॉर्मेंस और लचीलापन की ताकतों का उपयोग करता है, और टेस्ट रिक्वेस्ट जनरेट करने के लिए अपने खुद के Lua स्क्रिप्ट लिखने की क्षमता प्रदान करता है।

हालांकि wrk के पास कोई टेस्ट केस नहीं है और लेखक साल में लगभग एक बार कोड मर्ज करने के लिए दिखाई देता है, लेकिन यह हमें wrk को परफॉर्मेंस और फज़ टेस्टिंग के लिए अपने पसंदीदा टूल के रूप में उपयोग करने से नहीं रोकता है। यदि आप अभी भी मल्टी-थ्रेडेड ab का उपयोग कर रहे हैं, तो wrk को आज़माना बहुत ही उपयोगी हो सकता है।

निम्नलिखित wrk के परिणामों से विलंबता वितरण का सांख्यिकीय भाग है।

    Latency Distribution
     50%    1.20ms
     75%  595.78ms
     90%  899.11ms
     99%    1.00s

इस उदाहरण का मतलब है कि 50% रिक्वेस्ट 1.2ms में पूरी हो जाती हैं, 90% रिक्वेस्ट 899 ms में पूरी हो जाती हैं, और 99% रिक्वेस्ट 1s में पूरी हो जाती हैं।

जब हमने अपने उत्पाद का स्ट्रेस टेस्ट करने के लिए wrk का उपयोग किया, तो हमने पाया कि wrk के विलंबता सांख्यिकी में अधिकांश रिक्वेस्ट कुछ मिलीसेकंड में पूरी हो गईं, लेकिन रिक्वेस्ट का एक छोटा प्रतिशत 100 मिलीसेकंड से अधिक की विलंबता के साथ था। OpenResty के साथ बने सिस्टम के लिए, इतनी बड़ी विलंबता होना बहुत वैज्ञानिक नहीं है।

हालांकि इस समस्या का अंतिम समाधान बहुत सरल था, लेकिन विशिष्ट विश्लेषण और पोजिशनिंग थोड़ा जटिल था और इसमें कई दिन लग गए। अंतिम समाधान महत्वपूर्ण नहीं है; यह प्रक्रिया और समस्या के बारे में सोचने का तरीका है जो दिलचस्प है।

जब हम विलंबता समस्याओं का सामना करते हैं, तो हमारी पहली प्रतिक्रिया यह होती है कि कोड या सिस्टम में कहीं ब्लॉकेज है। चूंकि सिस्टम जटिल है, हम फ्लेम चार्ट प्रदान करते हैं।

इस तरह की समस्या का विश्लेषण करने के लिए कोई तैयार systemtap स्क्रिप्ट नहीं है, इसलिए इसे लिखने में कुछ समय लगा। हालांकि, systemtap स्क्रिप्ट को कई बार ट्वीक करने के बाद, कोई महत्वपूर्ण विलंबता कैप्चर नहीं की गई, जो स्पष्ट रूप से wrk के परिणामों से असंगत है। हमने अनुमान लगाया कि स्क्रिप्ट शायद पूरी तरह से परफेक्ट नहीं है और कुछ फंक्शन्स को हुक नहीं किया गया हो सकता है। लेकिन हमें wrk के परिणामों की सहीता पर भी संदेह है।

हम पलटकर यह पता लगाने की कोशिश करते हैं कि wrk के सांख्यिकी गलत हैं, या यह वास्तव में सर्वर की समस्या है। हमने wrk के स्थित सर्वर पर क्रश टेस्ट के सभी पैकेट्स को डंप किया, उन्हें समय के अनुसार क्रमबद्ध किया, और हैरानी से पाया कि परिणाम wrk के विलंबता सांख्यिकी से बहुत अलग थे, कोई भी रिक्वेस्ट 100 मिलीसेकंड से अधिक नहीं थी। मैंने उपरोक्त टेस्ट को कई बार दोहराया और परिणाम समान थे।

अब लक्ष्य स्पष्ट है, बस wrk के कोड को विलंबता सांख्यिकी के बारे में सही करना है। सबसे बड़ी चिंता यह है कि wrk के आंतरिक सांख्यिकी में कोई बग हो सकता है, जिसे ठीक करना आसान नहीं है, क्योंकि यह एक ऐसा प्रोजेक्ट है जिसमें कोई टेस्ट केस नहीं है।

हमने wrk के सांख्यिकी लॉजिक को देखा और शुरुआत और अंत में लॉग जोड़े, और राहत मिली कि विलंबता के बारे में सांख्यिकी सही थी। लेकिन अंतिम परिणाम प्रिंट करने से पहले, एक statistic correction कोड है।

    if (complete / cfg.connections > 0) {
        int64_t interval = runtime_us / (complete / cfg.connections);
        stats_correct(statistics.latency, interval);
    }

इस if जजमेंट के अनुसार, जब भी पीज़ोमेट्रिक डेटा जनरेट होता है, इसे सही किया जाएगा। यदि आप रुचि रखते हैं, तो stats_correct फंक्शन का कोड देख सकते हैं, यह केवल 10 लाइन्स का है, और मैं इसे कई बार पढ़ने के बाद भी समझ नहीं पाया।

कोड कमिट रिकॉर्ड को फिर से चेक करें, शायद कुछ हो, लेकिन केवल निम्नलिखित लाइन है, और समझ में नहीं आया:

remove calibration & improve CO correction

टुकाओ के तहत, यदि सबमिशन रिकॉर्ड थोड़ा और विस्तृत होता, संक्षिप्तीकरण के बिना, या कोड कमेंट जोड़ा जाता, तो बहुत सी चीजें बचाई जा सकती थीं।

समस्या यहां चेक की गई है, और यह पुष्टि की जा सकती है कि यह उत्पाद की समस्या नहीं है, और समाधान पहले से ही है, जो ऊपर के सही किए गए कोड को कमेंट आउट करना है। लेकिन wrk लेखक ने जानबूझकर इसे जोड़ा होगा, और इसका कारण न समझना हमेशा एक छिपी हुई समस्या है। स्वाभाविक रूप से, मुझे लेखक से पूछने के लिए एक इश्यू खोलना पड़ा, और wg, जो साल में एक बार दिखाई देता है, ने 15 दिन बाद जवाब दिया, और पता चला कि उपरोक्त कमिट इंफो में संक्षिप्तीकरण CO Coordinated Omission को संदर्भित करता है, और इस समस्या के लिए समर्पित एक लेख दिया, रुचि रखने वाले छात्र इस कीवर्ड का उपयोग करके खुद से खोज सकते हैं।

सरल शब्दों में, Coordinated Omission का मतलब है कि स्ट्रेस टेस्टिंग करते समय, केवल रिप्लाई भेजने और प्राप्त करने के बीच के समय को गिनना पर्याप्त नहीं है, यह सर्विस टाइम को संदर्भित करता है, जो बहुत सी संभावित समस्याओं को छोड़ देगा, और टेस्ट रिक्वेस्ट के इंतज़ार के समय को भी गिनना चाहिए, ताकि यह रिस्पॉन्स टाइम हो जो उपयोगकर्ताओं को चिंतित करता है।

CO समस्या को प्रस्तावित करने वाले Gil Tene ने wrk में एक संशोधन भी किया है जो विशेष रूप से CO समस्या को संबोधित करता है: https://github.com/giltene/wrk2, और इस प्रोजेक्ट के README में इसके बारे में कुछ स्पष्टीकरण हैं, जिन्हें आप पढ़ सकते हैं यदि आप रुचि रखते हैं, इसलिए मैं यहां इसका उल्लेख नहीं करूंगा।

हमारे अपने उत्पाद के लिए, कोड में निश्चित रूप से कोई ब्लॉकेज नहीं है, और स्ट्रेस टेस्ट करते समय, यह CPU को पूरी तरह से चला रहा है। यदि कोई ब्लॉकेज होता भी है, तो फ्लेम चार्ट है जो सैंपल ले सकता है और विश्लेषण कर सकता है। इसलिए Coordinated Omission के लिए wrk द्वारा किया गया यह सरल और क्रूर सुधार काफी भ्रामक है।