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 ले बाटो आफै स्थिर छ कि भनेर देखाउँछ, र तपाईंको आफ्नै अनुरोध टाइमरले एन्डपोइन्ट सुधार भयो कि भनेर देखाउँछ। ढिलाइको इतिहास समतल हुँदा पनि एन्डपोइन्ट ढिलो छ भने बाँकी लागत सर्भर-पक्षको काम वा तपाईंको आफ्नै क्रमबद्धीकरण हो, र अर्को कदम अर्को ब्याचिङ परिवर्तन होइन, ह्यान्डलरको प्रोफाइल हो।