VPN वर Redis संथ वाटतो: प्रति विनंती राउंड ट्रिप कमी करणे

स्थानिक Redis समोर 200 ms मध्ये उत्तर देणारे पान क्लायंट VPN मागे बसताच चार सेकंद घेते, तर सर्व्हरचे काउंटर रिकामे राहतात। संथ लॉग एका मिलिसेकंदापेक्षा जास्त काही दाखवत नाही, CPU चा आलेख सपाट आहे आणि इन्स्टन्स तक्रारीशिवाय इतर क्लायंटना सेवा देतो। बदललेले अंतर आहे आणि अंतराला गुणक करते तुमचा कोड किती वेळा थांबून वाट पाहतो। क्लायंटपासून बाहेरच्या दिशेने विनंतीचा मार्ग चाला आणि उपाय जवळजवळ नेहमीच वेगवान सर्व्हर नसून कमी क्रमिक वाट पाहणे असतो।

सर्व्हरच्या मेट्रिकपासून नाही, क्लायंटपासून सुरुवात करा

पहिल्या आदेशापासून शेवटच्या आदेशापर्यंत क्लायंट प्रक्रियेचे निरीक्षण करा। जर ट्रेस उत्तर, विराम आणि नंतर पुढचा आदेश दाखवत असेल, तर तुम्ही प्रत्येक आदेशासाठी पूर्ण राउंड ट्रिप भरत आहात आणि सर्व्हर ट्युनिंगच्या कोणत्याही प्रमाणात ते बदलणार नाही। संथ लॉग येथे चुकीचे साधन आहे, कारण तो अंमलबजावणीचा वेळ नोंदवतो आणि दळणवळण I/O हेतुपुरस्सर वगळतो। संथ एंडपॉइंटजवळ स्वच्छ संथ लॉग हे राउंड-ट्रिप समस्येचे स्वाक्षरी आहे।

कोडला स्पर्श करण्यापूर्वी मार्गच मोजा। redis-cli -h redis.example.internal --latency वारंवार PING पाठवतो आणि सरासरी विनंती व उत्तर वेळ छापतो, जो तुमचा प्रति-देवघेव खर्च आहे। एका वापरकर्ता क्रियेतील क्रमिक आदेशांच्या संख्येने गुणा आणि एंडपॉइंटसाठी किमान मर्यादा मिळेल।

एका वापरकर्ता क्रियेला खरोखर किती राउंड ट्रिप लागतात ते मोजा

एक एंडपॉइंट घ्या आणि प्रत्येक Redis कॉल क्रमाने लिहा, ORM, सत्र मिडलवेअर किंवा फीचर-फ्लॅग शोधात लपलेलेही समाविष्ट करा। बहुतेक संथ एंडपॉइंट तीन पुरतात तिथे वीस किंवा तीस कॉल करतात आणि लपलेले सहसा बहुमतात असतात।

अवलंबित्वाची साखळी दुमडता येत नाही: जर दुसऱ्या आदेशाला पहिल्याने परत दिलेली किल्ली लागत असेल, तर वाट पाहणे खरे आहे आणि एकमेव पर्याय म्हणजे वेगळे डेटा मॉडेल किंवा संपूर्ण पायरी एकाच वेळी व्यक्त करणारे सर्व्हर-बाजूचे ऑपरेशन। स्वतंत्र वाचन वेगळे प्रकरण आहे, कारण दुसरे पाठवण्यापूर्वी पहिल्या उत्तराची वाट पाहण्यास काहीही भाग पाडत नाही। काहीही संपादित करण्यापूर्वी प्रत्येक कॉल अवलंबित किंवा स्वतंत्र म्हणून चिन्हांकित करा आणि उपायाचा आकार स्पष्ट होईल।

महत्त्वाची संख्या क्रमिक वाट पाहणे आहे, एकूण आदेश नाही। एका बॅचमधील तीस आदेशही एकाच वाट पाहण्याचा खर्च करतात।

फक्त एकमेकांवर अवलंबून नसलेले आदेश बॅच करा

पाइपलाइन स्वतंत्र आदेश रांगेत ठेवते आणि उत्तरे क्रमाने गोळा करते, N वाट पाहण्यांचे एकात रूपांतर करते। बहुतेक क्लायंट हे वेगळ्या कनेक्शन मोडऐवजी ब्लॉक, कॉलबॅक किंवा संदर्भ व्यवस्थापक म्हणून देतात, म्हणून तुमच्या स्थापित आवृत्तीची API तपासा। फायदा राउंड-ट्रिप वेळेसोबत वाढतो आणि म्हणूनच VPN वर तो महत्त्वाचा असतो आणि localhost वर जवळपास जाणवत नाही।

import redis

r = redis.Redis(host="redis.example.internal", port=6379, socket_timeout=2)
pipe = r.pipeline(transaction=False)
for key in ("user:1001", "user:1002", "user:1003"):
    pipe.get(key)
print(pipe.execute())

फक्त बॅचिंग हवे असल्यास transaction=False द्या। डीफॉल्टनुसार क्लायंट बॅचला MULTI आणि EXEC मध्ये गुंडाळतो, ज्यामुळे ती अण्विक होते आणि इतर क्लायंट मध्ये काय पाहू शकतात ते बदलते। अण्विकता कार्यक्षमतेचा दांडा नाही, अचूकतेचा निर्णय आहे आणि दोन्ही राउंड ट्रिप कमी करतात म्हणूनच पाइपलाइन व्यवहार ठरत नाही।

फक्त बॅच सबमिशन नाही, प्रत्येक उत्तर वाचा। रांगेतील आदेश बॅच संपूर्ण होत असताना त्रुटी परत देऊ शकतो आणि उत्तरांची यादी फेकून देणारा क्लायंट अपयशी लेखनाचे शांत लेखन करतो। उत्तरांच्या यादीची लांबी तुम्ही रांगेत ठेवलेल्या आदेशांच्या संख्येशी तुलना करा।

क्रियांमध्ये कनेक्शन जिवंत ठेवा

प्रत्येक नवीन कनेक्शन नाव-निराकरण, TCP हातमिळवणी, TLS हातमिळवणी आणि AUTH साठी भरते आणि VPN वर त्यातील प्रत्येक बॅच करून काढता येणार नाही अशी राउंड ट्रिप आहे। प्रत्येक प्रक्रियेसाठी एकदा क्लायंट तयार करा आणि पुन्हा वापरा, किंवा तुमची लायब्ररी देते त्या मर्यादित आकाराच्या पूलचा वापर करा। प्रत्येक विनंतीला पुन्हा कनेक्ट होणे हे प्रति-आदेश वाट पाहण्यानंतर या लक्षणाचे दुसरे सर्वात सामान्य कारण आहे।

कॉन्फिगरेशनमध्ये शाब्दिक पत्त्याऐवजी खाजगी होस्टनाव ठेवा। खाजगी नेटवर्कवरही प्रमाणपत्र पडताळणी आणि सेवा ओळख लागू असते आणि IP पिन करणे प्रदात्याने सबनेट पुनर्क्रमांकित केल्याक्षणी तुटते। नाव-निराकरण संथ भाग असेल, तर कनेक्शन स्ट्रिंग नाही, रिझोल्व्हर मार्ग दुरुस्त करा।

स्पष्ट सॉकेट कालमर्यादा सेट करा जेणेकरून अडकलेली बोगदा कर्मचाऱ्याला लटकवण्याऐवजी लवकर अपयशी होईल। नंतर क्लायंटमध्ये कनेक्शन तयार होण्याची नोंद करून पूल खरोखर पुन्हा वापरला जातो याची खात्री करा।

स्मृती समस्या होण्यापूर्वी बॅचचा आकार ठरवा

Redis बॅचच्या संपूर्ण कालावधीत रांगेतील उत्तरे ठेवतो आणि क्लायंट नंतर विश्लेषित निकाल ठेवतो। दहा हजार मोठ्या मूल्यांची पाइपलाइन नेटवर्कच्या वाट पाहण्यांची स्मृती उसळ्या आणि दोन्ही टोकांवरील लांब विरामांशी देवघेव करते।

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

बदलानंतर सुरुवातीपासून शेवटपर्यंत मोजा: redis-cli -h redis.example.internal --latency-history मार्ग स्वतः स्थिर आहे का हे दाखवते आणि तुमचा स्वतःचा विनंती टाइमर एंडपॉइंट सुधारला का हे दाखवतो। विलंब इतिहास सपाट असूनही एंडपॉइंट संथ असेल, तर उर्वरित खर्च सर्व्हर-बाजूचे काम किंवा तुमचे स्वतःचे क्रमिकीकरण आहे आणि पुढचे पाऊल आणखी एक बॅचिंग बदल नाही, हँडलरची प्रोफाइल आहे।