प्रस्तावना
मैं कुछ समय के लिए HAProxy को ट्यून कर रहा हूं और इस पर बहुत सारे प्रदर्शन परीक्षण किए हैं। 100 HTTP अनुरोध / s से 50 000 HTTP अनुरोध / s तक।
पहली सलाह है कि HAProxy पर आँकड़े पृष्ठ को सक्षम करें । आप निगरानी की जरूरत है, कोई अपवाद नहीं है। यदि आपको पिछले 10,000 अनुरोधों को पूरा करने का इरादा है, तो आपको ठीक ट्यूनिंग की भी आवश्यकता होगी।
टाइमआउट एक भ्रामक जानवर हैं क्योंकि उनके पास संभावित मूल्यों की एक विशाल श्रृंखला है, उनमें से अधिकांश में कोई अवलोकन अंतर नहीं है। मुझे अभी तक 5% कम या 5% अधिक संख्या के कारण कुछ विफल दिखाई दे रहा है। 10000 बनाम 11000 मिलीसेकंड, कौन परवाह करता है? शायद आपका सिस्टम नहीं।
विन्यास
मैं अच्छे विवेक में 'सभी के लिए सर्वश्रेष्ठ टाइमआउट' के रूप में कुछ संख्या दे सकता हूं।
इसके बजाय मैं जो बता सकता हूं वह सबसे आक्रामक टाइमआउट है जो HTTP (एस) लोड संतुलन के लिए हमेशा स्वीकार्य है। यदि आप इन से कम मुठभेड़ करते हैं, तो यह आपके लोड बैलेंसर को फिर से कॉन्फ़िगर करने का समय है।
timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000
टाइमआउट क्लाइंट:
जब ग्राहक डेटा को स्वीकार करने या भेजने की अपेक्षा करता है तो निष्क्रियता का समय लागू होता है। HTTP मोड में, यह टाइमआउट पहले चरण के दौरान विचार करने के लिए विशेष रूप से महत्वपूर्ण है, जब क्लाइंट अनुरोध भेजता है, और प्रतिक्रिया के दौरान जब वह सर्वर द्वारा भेजे गए डेटा को पढ़ रहा होता है।
पढ़ें : यह क्लाइंट से HTTP रिक्वेस्ट हेडर प्राप्त करने का अधिकतम समय है ।
3G / 4G / 56k / उपग्रह कई बार धीमा हो सकता है। फिर भी, उन्हें HTTP हेडर को कुछ सेकंड में भेजने में सक्षम होना चाहिए, न कि 30।
यदि किसी का कनेक्शन इतना खराब है कि उसे एक पेज का अनुरोध करने के लिए 30 से अधिक की आवश्यकता है (तो 10 एम्बेडेड छवियों / सीएसएस / जेएस का अनुरोध करने के लिए 10 * 30 से अधिक), मेरा मानना है कि उसे अस्वीकार करना स्वीकार्य है।
टाइमआउट सर्वर:
निष्क्रियता का समय लागू होता है जब सर्वर को डेटा को स्वीकार करने या भेजने की उम्मीद होती है। HTTP मोड में, सर्वर की प्रतिक्रिया के पहले चरण के दौरान विचार करने के लिए यह टाइमआउट विशेष रूप से महत्वपूर्ण है, जब इसे हेडर भेजना होगा, क्योंकि यह अनुरोध के लिए सीधे सर्वर के प्रसंस्करण समय का प्रतिनिधित्व करता है। यह पता लगाने के लिए कि वहां क्या मूल्य रखा जाए, यह अक्सर अच्छा होता है कि जिसे अस्वीकार्य प्रतिक्रिया समय माना जाता है, उसके साथ शुरू करें, फिर प्रतिक्रिया समय वितरण का निरीक्षण करने के लिए लॉग की जांच करें, और तदनुसार मूल्य समायोजित करें।
पढ़ें : यह सर्वर से HTTP प्रतिक्रिया हेडर प्राप्त करने के लिए अधिकतम समय है (इसे पूर्ण ग्राहक अनुरोध प्राप्त होने के बाद)। मूल रूप से, यह आपके सर्वर से प्रोसेसिंग समय है, इससे पहले कि यह प्रतिक्रिया भेजना शुरू कर दे।
यदि आपका सर्वर इतना धीमा है कि उसे जवाब देना शुरू करने के लिए 30 से अधिक की आवश्यकता है, तो मेरा मानना है कि इसे मृत मान लेना स्वीकार्य है।
विशेष मामला : बहुत भारी प्रोसेसिंग करने वाली कुछ दुर्लभ सेवाएं उत्तर देने के लिए पूर्ण या अधिक समय ले सकती हैं। इस विशिष्ट उपयोग के लिए इस समय सीमा को बहुत अधिक बढ़ाने की आवश्यकता हो सकती है। (नोट: यह खराब डिज़ाइन का मामला होने की संभावना है, एक एसिंक्स शैली संचार का उपयोग करें या HTTP का उपयोग बिल्कुल न करें।)
टाइमआउट कनेक्ट:
सफल होने के लिए सर्वर से कनेक्शन के प्रयास के लिए अधिकतम समय निर्धारित करें।
पढ़ें : एक सर्वर के टीसीपी कनेक्शन को स्वीकार करने के लिए अधिकतम समय।
सर्वर HAProxy के समान LAN में हैं, इसलिए इसे तेज़ होना चाहिए। इसे कम से कम 5 सेकंड दें क्योंकि जब कुछ अनपेक्षित होता है तो कितना समय लग सकता है (रिट्रेसिट के लिए एक टीसीपी पैकेट खो जाता है, नया अनुरोध लेने के लिए एक सर्वर, ट्रैफ़िक में स्पाइक)।
विशेष मामला : जब सर्वर एक अलग लैन या एक अविश्वसनीय लिंक पर हैं। इस समयसीमा को बहुत अधिक बढ़ाने की आवश्यकता हो सकती है। (नोट: यह खराब वास्तुकला का मामला होने की संभावना है।)
समयबाह्य जांच:
अतिरिक्त चेक टाइमआउट सेट करें, लेकिन केवल एक कनेक्शन स्थापित होने के बाद ही।
अतिरिक्त चेक टाइमआउट सेट करें, लेकिन एक कनेक्शन पहले से ही होने के बाद ही यदि सेट किया गया है, तो हाइपर प्रॉक्सी मिनट ("टाइमआउट कनेक्ट", "इंटर") चेक के लिए कनेक्ट टाइमआउट के रूप में और "टाइमआउट चेक" अतिरिक्त रीड टाइमआउट के रूप में उपयोग करता है। "मिनट" का उपयोग किया जाता है ताकि बहुत लंबे समय तक "टाइमआउट कनेक्ट" के साथ चलने वाले लोग (जैसे। जिन्हें कतार या तारपिट के कारण इसकी आवश्यकता थी) उनके चेक को धीमा नहीं करते हैं। (कृपया यह भी ध्यान दें कि इस तरह के लंबे कनेक्ट टाइमआउट के लिए कोई वैध कारण नहीं है, क्योंकि "टाइमआउट कतार" और "टाइमआउट तारपिट" का उपयोग हमेशा उस से बचने के लिए किया जा सकता है)।
पढ़ें : स्वास्थ्य परीक्षण करते समय, सर्वर को timeout connectकनेक्शन स्वीकार करना पड़ता है, फिर timeout checkप्रतिक्रिया देने के लिए।
सभी सर्वरों में एक HTTP (S) स्वास्थ्य जांच विन्यस्त होनी चाहिए। लोड बैलेंसर के लिए यह जानना एकमात्र तरीका है कि सर्वर उपलब्ध है या नहीं। Healthcheck /isaliveहमेशा जवाब देने वाला एक सरल पृष्ठ है OK।
इस टाइमआउट को कम से कम 5 सेकंड दें क्योंकि ऐसा होने में कितना समय लग सकता है जब कुछ अनपेक्षित होता है (रिस्ट्रिक्ट करने के लिए एक खोई हुई टीसीपी पैकेट, नया अनुरोध करने के लिए एक नई प्रक्रिया के लिए एक सर्वर, ट्रैफ़िक में स्पाइक)।
युद्ध की कहानी : बहुत सारे लोग गलत तरीके से मानते हैं कि सर्वर हमेशा 3 एमएस में इस सरल पृष्ठ का जवाब दे सकता है। उन्होंने आक्रामक विफलता (2 विफल चेक = सर्वर डेड) के साथ एक आक्रामक टाइमआउट (<2000ms) सेट किया। मैंने इसकी वजह से पूरी वेबसाइटों को नीचे जाते देखा है। आमतौर पर ट्रैफ़िक में थोड़ी बहुत स्पाइक होती है, बैकएंड सर्वर धीमा हो जाता है, हेल्थचेक में देरी हो जाती है ... अचानक जब तक वे एक साथ सभी समय समाप्त हो जाते हैं, HAProxy को लगता है कि सभी सर्वर एक ही बार में मर गए और पूरी साइट डाउन हो गई।