Redis प्रदर्शन में महारत हासिल करना: कमांड लेटेंसी में एक गहरा गोता

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

क्या मापना है

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

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

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

बेसिक लेटेंसी

बेसिक लेटेंसी परिणाम प्राप्त करने के लिए redis-cli --latency चलाएं। यह मिन, मैक्स, एवरेज, और इटरेशन की संख्या दर्शाने वाले नंबरों का एक सेट आउटपुट करेगा। ये इटरेशन एक खुले कनेक्शन के खिलाफ Redis कमांड PING चलाने से मिलकर बने होते हैं। नतीजतन इसमें सर्वर से कनेक्ट होने में लगने वाला कोई समय शामिल नहीं है। यदि आपका कोड हर कमांड पर कनेक्ट होता है तो आप इस कमांड से संकेतित की तुलना में बहुत खराब प्रदर्शन देखेंगे।

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

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

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

वैकल्पिक रूप से, आप --latency-history का उपयोग कर सकते हैं। यह विकल्प आपको इसे अस्थायी स्लाइस में तोड़ने की अनुमति देता है। redis-cli --latency-history चलाने से 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

--latency की तरह, यह कमांड तब तक चलेगा जब तक आप इसे मार नहीं देते। यदि आप एक अलग अंतराल के साथ चलाना चाहते हैं तो आप -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

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

इंट्रिंसिक लेटेंसी

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

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

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

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

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

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

Commissar का उपयोग करना

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

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

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

लेटेंसी का एक रन ऐसा दिख सकता है, हालांकि आउटपुट तब से बदल गया होगा जब यह लेख लिखा गया था:

./latency
Connected to 
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

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

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

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

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

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

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

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

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

कंटेनरों से टेस्टिंग

Docker कंटेनरों से अपने टेस्ट चलाना पसंद करते हैं? मैं अब बिल्ट Docker कंटेनर्स को पब्लिक Docker रजिस्ट्री में पुश करता हूं जिनमें सिर्फ golatency टूल होता है। यदि आप docker pull therealbill/golatency करते हैं तो आपको इमेज मिल जाएगी, सेकंड में चलाने के लिए तैयार (यह वर्तमान में 4MB से कम इमेज साइज में है)।

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

अंतिम विचार

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