रेडिस के प्रदर्शन परिणामों का विश्लेषण

पिछली किस्त में मैंने आपके रेडिस इंस्टेंस को धीमा होने से रोकने के लिए विषयों और तरीकों पर चर्चा की थी। अब मापने . के तरीकों की जांच करने का समय आ गया है प्रदर्शन।

क्या मापें

इस किस्त के लिए, हम कमांड लेटेंसी और उसके घटकों को देख रहे हैं। क्यों? क्योंकि रेडिस सर्वर/लाइब्रेरी के माध्यम से आप जितने कमांड को पुश कर सकते हैं, वह प्रत्येक कमांड की गति का परिणाम है।

त्वरित और आसान:CLI

अपने कमांड लेटेंसी को जांचने का पहला तरीका कमांड लाइन क्लाइंट redis-cli . का उपयोग करना है . यह तेज़ है और आपको शुरू करने के लिए तत्काल चेकपॉइंट देता है। यहां उदाहरण सरलता के लिए लोकलहोस्ट का उपयोग करेंगे, लेकिन आपके सेटअप में आपको -h <host> का उपयोग करना चाहिए विकल्प और यदि आवश्यक हो -a <auth> और -p <port> ।

बुनियादी विलंबता

मूल विलंबता परिणाम प्राप्त करने के लिए रेडिस-क्ली-लेटेंसी चलाएं। यह न्यूनतम, अधिकतम, औसत, और पुनरावृत्तियों की संख्या को इंगित करने वाली संख्याओं का एक सेट आउटपुट करेगा। इन पुनरावृत्तियों में एक खुले कनेक्शन के खिलाफ रेडिस कमांड पिंग चलाना शामिल है। नतीजतन इसमें सर्वर से जुड़ने का कोई समय शामिल नहीं है। यदि आपका कोड प्रत्येक कमांड से जुड़ता है, तो आप इस कमांड द्वारा दर्शाए गए प्रदर्शन की तुलना में बहुत खराब प्रदर्शन देखेंगे।

यह आदेश तब तक चलेगा जब तक आप इसे समाप्त नहीं कर देते—आसानी से CTRL-C के माध्यम से किया जाता है। विलंबता संख्या मिलीसेकंड में हैं। इस प्रकार का परिणाम:

min: 0, max: 1, avg: 0.11 (11369 samples)

इसका मतलब है कि न्यूनतम विलंबता 1 मिलीसेकंड से कम थी, अधिकतम 1 मिलीसेकंड थी, औसत प्रति-पिंग विलंबता 0.11 मिलीसेकंड के साथ। हाँ, यह एक लोकलहोस्ट कनेक्शन है। ये संख्याएं 11,369 "नमूनों" या पिंग कमांड से परिकलित परिणाम हैं।

वैकल्पिक रूप से, आप इसके बजाय -लेटेंसी-इतिहास का उपयोग कर सकते हैं। यह विकल्प आपको इसे अस्थायी स्लाइस में तोड़ने की अनुमति देता है। रेडिस-क्ली-लेटेंसी-हिस्ट्री चलाना 15 सेकंड की डिफ़ॉल्ट विंडो का उपयोग करेगा। परिणाम कुछ इस तरह दिखेगा:

min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds range

जैसे-लेटेंसी, यह कमांड तब तक चलेगा जब तक आप इसे मार नहीं देते। यदि आप एक अलग अंतराल के साथ दौड़ना चाहते हैं तो आप -i पास कर सकते हैं। उदाहरण के लिए:

redis-cli --latency-history  -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range

चूंकि ये ऑपरेशन केवल पिंग कमांड का उपयोग करते हैं, इसलिए इसे रेडिस के किसी भी संस्करण के खिलाफ काम करना चाहिए।

आंतरिक विलंबता

पहली नज़र में, नाम आपको विश्वास दिला सकता है कि आंतरिक विलंबता मोड सर्वर की आंतरिक विलंबता को माप रहा है। यह नहीं है। यदि आप गिटहब पर रेडिस-क्ली स्रोत को देखते हैं तो आप पाएंगे कि यह सर्वर से बात भी नहीं करता है:

start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;

स्रोत के अनुसार आंतरिक विलंबता मोड पर टिप्पणी:

एक चल रही प्रक्रिया की अधिकतम विलंबता को मापें जो syscalls के परिणामस्वरूप नहीं होती है। मूल रूप से इस सॉफ़्टवेयर को इस बात का संकेत देना चाहिए कि कर्नेल कितने समय तक बिना किसी अवसर के प्रक्रिया को छोड़ता है।

यह क्या कर रहा है आपके क्लाइंट होस्ट पर intrinsic आंतरिक विलंबता का परीक्षण कर रहा है . यह जानने के लिए उपयोगी है कि क्या समस्या वास्तव में सर्वर के बजाय क्लाइंट की तरफ है।

इसलिए उपयोगी होते हुए भी यह संभवत:आपकी विलंबता की जांच करने के आपके पहले चरण में नहीं होना चाहिए। अपडेट करें :सल्वाटोर से बात करने के बाद उन्होंने पुष्टि की है कि इस आदेश को सर्वर से चलाने का इरादा है। इसका मतलब यह है कि यह उपयोगी हो सकता है यदि आपके पास अपने रेडिस सर्वर तक शेल पहुंच है, लेकिन अन्यथा उपयोगी नहीं है - जो आमतौर पर ऐसा होता है यदि आप रेडिस सेवा प्रदाता का उपयोग करते हैं।

कमिसार का उपयोग करना

कमिसर एक छोटा सूट है जिस पर मैं रेडिस विलंबता और समग्र प्रदर्शन को ट्रैक और परीक्षण करने के लिए काम कर रहा हूं। चेतावनी:यह विकास की शुरुआत में है और बहुत कुछ बदलने की संभावना है। इस कारण से, इसका उपयोग केवल तभी करें जब आप गैर-उत्पादन गुणवत्ता वाले सॉफ़्टवेयर का उपयोग करने में सहज महसूस करें। कमिसार जीथब कमिसार रिपोजिटरी में है।

विशेष रूप से इस लेख के लिए हम लेटेंसी टूल/डायरेक्टरी को देखेंगे।

पर्यावरण चर के माध्यम से कॉन्फ़िगर किया गया यह उपकरण, किसी दिए गए रेडिस इंस्टेंस से कनेक्ट होगा और रेडिस-क्ली के समान "पिंग कमांड का समय" तंत्र चलाएगा। मैंने परीक्षण की समानता बनाए रखने के लिए ऐसा किया। जहां यह अधिक जानकारी को आउटपुट करने की क्षमता में भिन्न होता है और (वर्तमान में) इसे MongoDB में संग्रहीत करता है - आने वाले और अधिक स्टोर के साथ।

विलंबता का एक भाग इस तरह दिख सकता है, हालांकि इस लेख के लिखे जाने के बाद से आउटपुट में बदलाव होने की संभावना है:

./latency 
Connected to <host:ip>

100000 iterations over 53698us, average 536us/operation

Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us

Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37us

ध्यान दें कि इस रन में अस्थायी इकाई 'हम' (यानी माइक्रोसेकंड) है। साथ ही, आप देख सकते हैं कि यह आपको पर्सेंटाइल ब्रेकआउट देगा। यह आपको एक साधारण न्यूनतम/अधिकतम/औसत की तुलना में विलंबता कैसा दिखता है, इसकी बेहतर तस्वीर प्राप्त करने देता है। इस संदर्भ में 'घबराना' नमूने का मानक विचलन है।

यह आउटपुट हमें बताता है कि कुल मिलाकर हम बहुत अच्छे दिख रहे हैं। यह विशेष उदाहरण एक निजी नेटवर्क पर है। हम देख सकते हैं कि शिखर माध्य से बहुत अधिक है, लेकिन 95% पुनरावृत्तियाँ 640 माइक्रोसेकंड पर या उससे कम में आती हैं। यह हमें क्या बताता है?

यह हमें बता सकता है कि एक छिटपुट नेटवर्क समस्या है, एक छिटपुट सर्वर-साइड देरी है, या यहां तक ​​​​कि आउटपुट को प्रभावित करने वाले परीक्षण क्लाइंट में कचरा नियंत्रण जैसा कुछ है। यही कारण है कि अनुरोधों का वितरण उपलब्ध कराया जाता है:ताकि आप देख सकें कि "उच्च" परिणाम कितना सामान्य है।

यह निर्धारित करने के लिए कि समस्या कहाँ है, आप पहले यह देखना चाहेंगे कि सर्वर पर कमांड कितने समय ले रहे हैं। यह हमें बताएगा कि क्या सर्वर में समस्या है।

इस मामले में, उदाहरण के लिए, आप विशेष रूप से कमांडस्टैट्स अनुभाग को देखते हुए, रेडिस जानकारी आउटपुट की जांच करना चाह सकते हैं:

redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68

यहां हम देख सकते हैं कि सर्वर पर पिंग निष्पादित करने का औसत समय 0.68 माइक्रोसेकंड है। स्पष्ट रूप से पिंग कमांड ही अपराधी नहीं है। हालाँकि, परीक्षण के दौरान अन्य कमांड निष्पादित हो सकते हैं जो Redis प्रक्रिया का समर्थन करते हैं जिससे विलंब होता है।

विलंबता उपकरण में हाल ही में जोड़ा गया एक समवर्ती विलंबता परीक्षण चलाने की क्षमता है। LATENCY_CLIENTCOUNT में परिवेश चर सेट करके, आप अपने Redis सर्वर से कई कनेक्शन चला सकते हैं और देख सकते हैं कि समवर्ती आपके विलंबता परिणामों को कितना प्रभावित करता है। उदाहरण के लिए, आप एक साधारण रेडिस पिंग कमांड द्वारा देखे गए अंतर को देख सकते हैं जब आपके पास 10 क्लाइंट बनाम 100, या यहां तक ​​​​कि 1000 समवर्ती क्लाइंट होते हैं। विकास/स्टेजिंग और उत्पादन के बीच आप जो अंतर अनुभव कर रहे हैं उसे देखने के लिए यह उपयोगी हो सकता है।

कंटेनरों से परीक्षण

डॉकर कंटेनरों से अपने परीक्षण चलाना पसंद करते हैं? अब मैं निर्मित डॉकर कंटेनरों को धक्का देता हूं जिनमें सार्वजनिक डॉकर रजिस्ट्री में केवल गॉलेटेंसी टूल होता है। यदि आप डॉकर पुल रियालबिल/गोलेटेंसी करते हैं तो आपको छवि मिल जाएगी, जो कुछ ही सेकंड में चलने के लिए तैयार है (इसका वजन वर्तमान में 4MB से कम छवि आकार में है)।

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

अंतिम विचार

रेडिस के साथ अपने प्रदर्शन का विश्लेषण करना मुश्किल हो सकता है। सौभाग्य से, विलंबता और थ्रूपुट की समझ के साथ और वे आपके आवेदन को कैसे प्रभावित करते हैं, आप रेडिस के बजाय अपने आवेदन के रेडिस के उपयोग का विश्लेषण करने पर अधिक ध्यान केंद्रित कर सकते हैं। आप अपने उपयोग और समझ में सुधार करेंगे कि रेडिस के ज़ेन के वाक्यांश "प्रदर्शन की कुंजी रेडिस को धीमा नहीं कर रहा है" को ध्यान में रखते हुए रेडिस का सबसे अच्छा उपयोग कैसे करें, जबकि नेटवर्क मुद्दों और डेटा संरचना विकल्पों को अलग करके स्मार्ट, अधिक कुशल अनुप्रयोगों का उत्पादन करें। , जिसके परिणामस्वरूप बेहतर प्रदर्शन होता है।