विली ने मुझे ईमेल द्वारा जवाब दिया। मैंने सोचा कि मैं इसे साझा करूंगा। उनके जवाब बोल्ड में हैं।
मैं अपने haproxy config संबंधित कोई प्रश्न है:
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 syslog emerg
maxconn 4000
quiet
user haproxy
group haproxy
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option abortonclose
option dontlognull
option httpclose
option httplog
option forwardfor
option redispatch
timeout connect 10000 # default 10 second time out if a backend is not found
timeout client 300000 # 5 min timeout for client
timeout server 300000 # 5 min timeout for server
stats enable
listen http_proxy localhost:81
balance roundrobin
option httpchk GET /empty.html
server server1 myip:80 maxconn 15 check inter 10000
server server2 myip:80 maxconn 15 check inter 10000
आप देख सकते हैं यह सीधे आगे है, लेकिन मैं थोड़ा के बारे में कैसे maxconn गुण काम उलझन में हूँ।
सुनो ब्लॉक में सर्वर पर वैश्विक एक और maxconn है।
और वहाँ भी सुनने ब्लॉक में एक और एक कुछ तरह 2000.
मेरे सोच को जो चूक यह है: वैश्विक एक, कनेक्शन कि HAProxy की कुल संख्या का प्रबंधन करता है एक सेवा के रूप, एक बार में que या प्रक्रिया होगी।
सही। यह समवर्ती कनेक्शन की प्रति-प्रक्रिया अधिकतम संख्या है।
संख्या कि ऊपर हो जाता है, यह या तो कनेक्शन, या कुछ linux सॉकेट में पूल को मारता है?
बाद में, यह केवल नए कनेक्शन स्वीकार करना बंद कर देता है और वे कर्नेल में सॉकेट कतार में रहते हैं। Queuable सॉकेट की संख्या निर्धारित है (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, और सुनें ब्लॉक के maxconn) के मिनट से।
मुझे नहीं पता कि संख्या एक दूसरे के लिए स्वीकार किए जाते हैं होने से पहले पूरा करने के लिए अधिक 4000.
अतिरिक्त कनेक्शन इंतजार हो जाता है तो क्या होगा है। हालांकि, जब तक कर्नेल की कतार संतृप्त नहीं होती है, क्लाइंट यह भी ध्यान नहीं देता है, क्योंकि कनेक्शन टीसीपी स्तर पर स्वीकार किया जाता है लेकिन संसाधित नहीं किया जाता है। इसलिए क्लाइंट अनुरोध को संसाधित करने के लिए केवल कुछ देरी को नोटिस करता है। लेकिन व्यवहार में, सुनो ब्लॉक का maxconn अधिक महत्वपूर्ण है, डिफ़ॉल्ट रूप से यह वैश्विक से छोटा है। सुनो का maxconn प्रति श्रोता कनेक्शन की संख्या को सीमित करता है। आम तौर पर यह सेवा के लिए इच्छित कनेक्शनों की संख्या के लिए कॉन्फ़िगर करना है, और कनेक्शन की अधिकतम संख्या में वैश्विक maxconn को कॉन्फ़िगर करने के लिए आप हैप्रोक्सी प्रक्रिया संभालते हैं। जब आपके पास केवल एक सेवा है, दोनों को एक ही मान पर सेट किया जा सकता है। लेकिन जब आपके पास कई सेवाएं हैं, आप आसानी से समझ सकते हैं कि यह एक बड़ा अंतर बनाता है, क्योंकि आप नहीं चाहते हैं कि एक ही सेवा सभी कनेक्शन ले लें और अन्य लोगों को काम करने से रोकें।
तो फिर तुम सर्वर maxconn संपत्ति 15. सबसे पहले पर सेट है, मैं सेट कि 15 क्योंकि मेरे php-एफ पी एम, यह एक अलग सर्वर पर को अग्रेषित किया जाता है, केवल इतने सारे बच्चे प्रक्रियाओं में उपयोग कर सकते है , इसलिए मैं सुनिश्चित करता हूं कि मैं php-fpm में बजाय अनुरोधों को पूल कर रहा हूं। जो मुझे लगता है तेज़ है।
हाँ, न केवल यह तेजी से होना चाहिए, लेकिन यह जब भी संभव हो एक और उपलब्ध सर्वर को खोजने के लिए haproxy अनुमति देता है, और यह भी अगर ग्राहक कनेक्शन से पहले हिट "रोक" यह कतार में अनुरोध को मारने के लिए अनुमति देता है सर्वर पर अग्रेषित है।
लेकिन इस विषय पर वापस, इस नंबर के बारे में मेरा सिद्धांत इस ब्लॉक में प्रत्येक सर्वर को केवल एक समय में 15 कनेक्शन भेजे जाएंगे। और फिर कनेक्शन एक खुले सर्वर की प्रतीक्षा करेगा। अगर मेरे पास कुकीज़ थी, तो कॉररेक्ट ओपन सर्वर के लिए कनेक्शन का इंतजार करेंगे। लेकिन मैं नहीं करता।
यह बिल्कुल सिद्धांत है। प्रति-प्रॉक्सी कतार और प्रति-सर्वर कतार है। एक दृढ़ता कुकी के साथ कनेक्शन सर्वर कतार में जाते हैं और अन्य कनेक्शन प्रॉक्सी कतार में जाते हैं। हालांकि, आपके मामले में कुकी कॉन्फ़िगर की गई है, इसलिए सभी कनेक्शन प्रॉक्सी कतार में जाते हैं। यदि आप चाहते हैं तो हैप्रोक्सी स्रोतों में आरेख दस्तावेज़/queuing.fig पर देख सकते हैं, यह बताता है कि निर्णय/कहां लिया जाता है।
तो प्रश्न हैं:
अगर वैश्विक कनेक्शन 4000 से ऊपर मिलता है तो क्या होगा? क्या वे मर जाते हैं? या किसी भी तरह लिनक्स में पूल?
वे लिनक्स में कतारबद्ध हैं। एक बार जब आप कर्नेल की कतार को भर देते हैं, तो वे कर्नेल में गिराए जाते हैं।
वैश्विक कनेक्शन सर्वर कनेक्शन से संबंधित, अन्य से सच है कि आप से वैश्विक अधिक से अधिक सर्वर कनेक्शन की कुल संख्या नहीं हो सकती हैं?
नहीं, वैश्विक और सर्वर कनेक्शन सेटिंग्स स्वतंत्र हैं।
जब वैश्विक कनेक्शन का पता लगाना है, यह कनेक्शन सर्वर अनुभाग में जोड़ा की राशि, प्लस पूलिंग के लिए एक निश्चित प्रतिशत नहीं किया जाना चाहिए? और जाहिर है आप कनेक्शन पर अन्य प्रतिबंध हैं, लेकिन वास्तव में यह है कि आप प्रॉक्सी को कितने भेजना चाहते हैं?
आपको यह सही मिला। यदि आपके सर्वर का प्रतिक्रिया समय छोटा है, तो कुछ भी नहीं है जो हजारों कनेक्शनों को क्यूइंग करने के साथ गलत है, क्योंकि यह अनुरोध प्रसंस्करण समय को काफी कम करता है। व्यावहारिक रूप से, आजकल कनेक्शन स्थापित करने के लिए गीगाबिट LAN पर लगभग 5 माइक्रोसॉन्ड लेते हैं। इसलिए यह बहुत ही समझ में आता है कि haproxy कनेक्शन को को अपने कतार से जितना तेज़ हो सके, एक बहुत छोटे maxconn के साथ सर्वर को वितरित करने दें। मुझे याद है कि एक गेमिंग साइट 30000 से अधिक समवर्ती कनेक्शन क्यूइंग और 30 प्रति सर्वर की कतार के साथ चल रही है! यह एक अपाचे सर्वर था, और बड़े संख्याओं की तुलना में कनेक्शन की छोटी संख्या के साथ अपाचे बहुत तेज है। लेकिन इसके लिए आपको वास्तव में एक तेज सर्वर की आवश्यकता है, क्योंकि आप नहीं चाहते हैं कि आपके सभी क्लाइंट कनेक्शन कनेक्शन स्लॉट के लिए प्रतीक्षा कर रहे हों क्योंकि सर्वर उदाहरण के लिए डेटाबेस की प्रतीक्षा कर रहा है। कुछ भी जो बहुत अच्छी तरह से काम करता है सर्वर को समर्पित करना है। यदि आपकी साइट में कई स्टेटिक्स हैं, तो आप स्थिर अनुरोधों को सर्वर (या कैश) के पूल पर निर्देशित कर सकते हैं ताकि आप उन पर स्थिर अनुरोधों को कतार न दें और स्थिर अनुरोध महंगा कनेक्शन स्लॉट नहीं खाते हैं। आशा इस मदद करता है, विली
इस पोस्ट करने के लिए धन्यवाद। – Tarantula
मेरे पास एक हैप्रोक्सी है जो लगभग 200 अन्य बैकएंड के लिए प्रॉक्सी करती है। एक बार बैकएंड डीडीओएस-एड के बारे में ~ 300k कनेक्शन/सेकेंड के साथ था, अन्य सभी बैकएंड मर जाते थे। बैकएंड सर्वर (डीडीओएस के तहत) पर वैल्यू मैक्सकॉन 2048 के साथ, हमारे हैप्रोक्सी ठीक चलते हैं। बहुत बहुत धन्यवाद, आपने मुझे एक रात बचाया :) – hungnv
विली == भगवान ... – cherouvim