ऐसा लगता है कि ईएलबी के परिप्रेक्ष्य से इसकी प्रतिक्रिया उत्पन्न करने के लिए सर्वर कितना समय ले रहा है, इस बात के बावजूद कि ईएलबी के लिए ग्राहक को प्रतिक्रिया वापस करने के लिए कितनी देर की आवश्यकता हो सकती है।
मैं अपने निष्कर्षों में से किसी एक में अपने स्वयं के लॉग की समीक्षा करके इस निष्कर्ष पर आया, जो ईएलबी का उपयोग अन्य लोड बैलेंसर, हैप्रोक्सी के सामने करता है, जो बदले में वास्तविक एप्लिकेशन सर्वर के सामने है। (यह निरर्थक लग सकता है, लेकिन यह केवल ईएलबी या केवल HAProxy का उपयोग करने पर हमें कई फायदे देता है।)
यहाँ सेटअप मैं की बात कर रहा हूँ: प्रत्येक अनुरोध पर
ELB -->>-- EC2+HAProxy -->>-- EC2+Nginx (multipe instances)
HAProxy लॉग several time metrics एक सहित Tr कहा जाता है।
Tr: सर्वर प्रतिक्रिया समय (केवल HTTP मोड)। यह उस समय के बीच समाप्त हो गया है जब सर्वर पर टीसीपी कनेक्शन स्थापित किया गया था और जिस समय सर्वर ने अपना पूरा प्रतिक्रिया शीर्षलेख भेजा था। डेटा ट्रांसमिशन के कारण नेटवर्क ओवरहेड के बिना यह पूरी तरह से प्रसंस्करण समय दिखाता है।
अब, एचएपीआरएक्सई क्या कर रहा है, इस बारे में इतनी अधिक चर्चा क्यों करें कि ईएलबी और लेटेंसी मेट्रिक के लिए प्रासंगिक क्यों है, इस बारे में एक स्पष्टीकरण के लिए मेरे साथ रहें।
हालांकि HAProxy दूसरे से संबंधित टाइमर के एक नंबर लॉग कब तक प्रॉक्सी, इस Tr टाइमर मेरी HAProxy लॉग में एक टाइमर है कि बड़े करीने से मूल्यों द्वारा लॉग से मेल खाती है है प्रत्येक अनुरोध/प्रतिक्रिया पर विभिन्न घटनाओं के लिए इंतज़ार कर खर्च करता है ईएलबी के लिए क्लाउडवॉच की "लेटेंसी" मीट्रिक एक मिनट-दर-मिनट आधार पर, मिलीसेकंड या दो ले लो या अन्य ... जंगली रूप से भिन्न हैं ... इसलिए मैं सुझाव दूंगा कि यह ईएलबी मीट्रिक इसी तरह प्रतिक्रिया समय को लॉग कर रहा है आपके एप्लिकेशन सर्वर का, उस समय के साथ असंबंधित जो क्लाइंट को प्रतिक्रिया देने के लिए आवश्यक हो सकता है।
यह हैप्रोक्सी और ईएलबी के लिए समझौते में इतनी लगातार होने की संभावना बहुत कम है, अन्यथा, प्रश्न में टाइमर की हैप्रोक्सी की परिभाषा दी गई है, जब तक कि ईएलबी का टाइमर एचएपीआरसीई मापने के समान कुछ न हो, क्योंकि ये सिस्टम हैं वही सटीक अनुरोधों पर समान सटीक ऐप सर्वर के प्रदर्शन को शाब्दिक रूप से मापना।
आपके आवेदन सर्वर पर ही बेंचमार्क नहीं है और लॉग अपने स्वयं के प्रदर्शन के टाइमर हैं, तो आप, उन्हें जोड़ने के बाद से विचार कर सकते हैं विलंबता मीट्रिक के लिए उच्च मूल्यों (मेरी टिप्पणियों के अनुसार) सुझाव देने के लिए लग रहे है कि आपके एप्लिकेशन में एक प्रतिक्रिया समस्या हो सकती है जो क्लाइंट कनेक्शन गुणवत्ता से संबंधित नहीं है।
इस उत्तर के लिए धन्यवाद धन्यवाद। क्या आपके पास विचार है कि किसी को अपने बैक एंड के विलंबता प्रदर्शन को कैसे मापना चाहिए यदि मुझे केवल पूरे पोस्ट बॉडी प्राप्त होने की परवाह है, यानी क्लाइंट थ्रूपुट की परवाह नहीं है? –