HAproxy सरल रिवर्स प्रॉक्सी बहुत धीमा है


0

मैं वर्तमान में वेबसाइटों के एक जोड़े के लिए एक रिवर्स प्रॉक्सी के रूप में कार्य करने के लिए एक HAproxy मशीन स्थापित कर रहा हूं। चूंकि विभिन्न मशीनें शारीरिक रूप से जुड़ी नहीं हैं, मैं मशीनों के बीच वीपीएन बनाने के लिए ओपनवीपीएन का उपयोग कर रहा हूं।

तकनीकी रूप से, सब कुछ काम कर रहा है। हालाँकि, मेरी समस्या यह है कि अनुरोध है कि मैं प्रॉक्सी के माध्यम से पाइप बहुत धीमी है। मुझे अंततः पूर्ण प्रतिक्रिया मिलती है, लेकिन जेनकिंस डैशबोर्ड की तरह कुछ प्राप्त करने में 5 मिनट तक का समय लगता है।

मैंने NGINX के माध्यम से एक साधारण स्टेटिक HTML पेज की कोशिश की और साथ ही कुछ REST API को भी लागू किया - परिणाम हमेशा एक जैसा होता है: मुझे अंततः डेटा मिलता है लेकिन यह एक हास्यास्पद राशि लेता है।

यहाँ मेरा HAproxy config है:


  global
          log /var/run/log local0 info
          log /var/run/log local0 notice
          daemon
          maxconn 8000
          tune.ssl.default-dh-param 2048
          user nobody
          group nobody

  defaults
          log global
          option httplog
          option dontlognull
          mode http
          timeout connect 5s
          timeout client 1min
          timeout server 1min
          option forwardfor
          option http-server-close
          errorfile 400 /usr/local/etc/haproxy/errorfiles/400.http
          errorfile 403 /usr/local/etc/haproxy/errorfiles/403.http
          errorfile 408 /usr/local/etc/haproxy/errorfiles/408.http
          errorfile 500 /usr/local/etc/haproxy/errorfiles/500.http
          errorfile 502 /usr/local/etc/haproxy/errorfiles/502.http
          errorfile 503 /usr/local/etc/haproxy/errorfiles/503.http
          errorfile 504 /usr/local/etc/haproxy/errorfiles/504.http

  frontend http-in
          bind *:80
          bind *:443 ssl crt /usr/local/etc/haproxy/certs/foo.my.org.pem
          mode http
          use_backend jenkins if { hdr(host) -i foo.my.org }
          use_backend test if { hdr(host) -i bar.my.org }
          default_backend test

  backend jenkins
          server jenkins1 <vpn_ip>:8180
          mode http
          http-request set-header X-Forwarded-Port %[dst_port]
          http-request add-header X-Forwarded-Proto https if { ssl_fc }
          reqrep ^([^\ :]*)\ /(.*)     \1\ /\2
          acl response-is-redirect res.hdr(Location) -m found
          rspirep ^Location:\ (http)://<vpn_ip>:8180/(.*)   Location:\ https://foo.my.org:443/\2  if response-is-redirect

  backend test
          server web01 <vpn_ip>:80

अतिरिक्त जानकारी:

  • सभी शामिल मशीनें डेटा केंद्रों में स्थित हैं और 1G / 1G इंटरनेट कनेक्शन की सुविधा प्रदान करती हैं
  • सभी मशीनें FreeBSD 11 64-Bit चलाती हैं
  • सभी मशीनों पर OpenVPN संस्करण 2.4.4
  • HAproxy संस्करण 1.7.9
  • OpenVPN टीसीपी मोड में चलता है
  • जेनकिंस के लिए HAproxy बैकएंड कॉन्फिगर को जेनकिंस डॉक्यूमेंट से प्रदान किया गया है, लेकिन जैसा कि उल्लेख किया गया है कि यह समस्या नंगे स्थिर HTML सामग्री वेबसर्वर और REST API वेब सेवा के साथ मौजूद है।

और जेनकिंस साइट तक पहुँचने पर यहाँ कुछ HAproxy लॉग हैं:

Feb 27 01:32:24 hostname haproxy[5539]: 213.144.130.227:60243 [27/Feb/2018:01:32:24.093] http-in~ jenkins/jenkins1 0/0/13/134/161 302 153 - - ---- 5/5/0/0/0 0/0 "GET /jenkins HTTP/1.1"
Feb 27 01:32:24 hostname haproxy[5539]: 213.144.130.227:19404 [27/Feb/2018:01:32:24.255] http-in~ jenkins/jenkins1 0/0/25/174/212 200 4492 - - ---- 5/5/0/0/0 0/0 "GET /jenkins/ HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:16321 [27/Feb/2018:01:32:25.330] http-in~ jenkins/jenkins1 0/0/13/30/54 200 8560 - - ---- 6/6/4/4/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/datasource/datasource-min.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:54637 [27/Feb/2018:01:32:25.330] http-in~ jenkins/jenkins1 0/0/27/29/58 200 7585 - - ---- 6/6/3/4/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/autocomplete/autocomplete-min.js HTTP/1.1"Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:59247 [27/Feb/2018:01:32:25.361] http-in~ jenkins/jenkins1 0/0/25/16/51 200 9602 - - ---- 6/6/2/3/0 0/0 "GET /jenkins/static/aeed77bb/jsbundles/page-init.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:40637 [27/Feb/2018:01:32:25.332] http-in~ jenkins/jenkins1 0/0/38/18/81 200 16212 - - ---- 6/6/1/1/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/menu/menu-min.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:10976 [27/Feb/2018:01:32:25.333] http-in~ jenkins/jenkins1 0/0/37/30/95 200 29110 - - ---- 6/6/0/0/0 0/0 "GET /jenkins/static/aeed77bb/scripts/hudson-behavior.js HTTP/1.1"
मुझे लॉग फ़ाइलों में और कुछ नहीं दिखता है। कोई त्रुटि या समान नहीं।

क्या यह ओपनवीपीएन के कारण हो सकता है?

संपादित 1: इस बीच में मैंने सीधे तौर पर HAproxy कॉन्फ़िगरेशन में वेब सर्वर के सार्वजनिक आईपी पते का उपयोग करके OpenVPN के बिना यह परीक्षण किया। परिणाम ठीक वैसा ही है।


बॉक्स से बाहर NginX का उपयोग क्यों नहीं किया?
बर्थ

क्योंकि मुझे कुछ बैक-एंड्स के लिए लोड बैलेंसिंग की आवश्यकता होगी जो कि पालन करेंगे।
जोएल बोडमैन

जवाबों:


0

आपके लॉग में 5 मिनट के इंतजार को समझाने के लिए पर्याप्त जानकारी शामिल नहीं है - यह 2 सेकंड से कम तक फैला हुआ है - लेकिन यहां वही है जो कूदता है:

option http-server-close

WAN लिंक के दूसरी ओर बैक-एंड के साथ यह उचित नहीं है। यदि आपको वास्तव में इस सुविधा की आवश्यकता है, तो इसे बैक-एंड सर्वर पर बेहद कम विलंबता (जैसे, स्थानीय) के साथ एक HAProxy पर होना चाहिए।

अपने Tcटाइमर मूल्यों में बड़ी मात्रा में घबराना नोट करें । यह लॉग फ़ील्ड का तीसरा मान है जो इस तरह दिखता है:

Tq/Tw/Tc/Tr/Tt

तो, पहली प्रविष्टि में 0/0/13/134/161, Tcमूल्य 13 एमएस है। Tcक्या बैक-एंड से संबंध स्थापित करने के लिए समय की आवश्यकता है, इसलिए हम यहां जो देखते हैं वह यह है कि आपकी गोल-यात्रा घबराहट नियंत्रण से बहुत दूर है, एक मामले में इस मूल्य के लगभग तीन गुना तक कूद। मान लें कि यह बैक-एंड सर्वर पर अपर्याप्त संसाधनों के कारण नहीं है, तो यह टीसीपी मोड में ओपनवीपीएन का उपयोग करने का परिणाम है - संभवतः, लेकिन जरूरी नहीं कि कुछ पैकेट नुकसान का संकेत हो।

आप टीसीपी (ओपनवीपीएन) के अंदर टीसीपी (एचटीटीपी) को टनल कर रहे हैं, जो आमतौर पर गैर-इंटरैक्टिव अनुप्रयोगों और अनुप्रयोगों के लिए ठीक है जहां घबराना महत्वहीन है, लेकिन अन्यथा नहीं। (देखें, उदाहरण के लिए, टीसीपी पर टीसीपी संभावित मेल्टडाउन परिदृश्यों में से एक की चर्चा के लिए एक बुरा आइडिया क्यों है, हालांकि इस कॉन्फ़िगरेशन को पूरी तरह से एक साफ नेटवर्क पर बचने का पर्याप्त कारण नहीं है।) के माध्यम से मैं OpenVPN की कोई गलती नहीं मानता हूं। टीसीपी सुरंगों में यूडीपी सुरंगों के समान सुसंगत विलंबता नहीं है। सुरंग के माध्यम से पिंग और आप पिंग प्रतिक्रिया समय के लिए प्रदान की गई इस घबराना देखना चाहिए।

सुरंग को यूडीपी में बदलें और मुद्दा गायब हो जाना चाहिए ... लेकिन ध्यान दें कि इस घबराहट का महत्व और प्रदर्शन प्रभाव - मुझे लगता है कि मैं सही हूं कि यह टीसीपी सुरंग का उपयोग करने का एक दुष्प्रभाव है - शायद उपयोग करके अतिरंजित है option http-server-close, जो आवश्यकता है कि प्रत्येक अनुरोध HAProxy और बैक-एंड के बीच एक नया कनेक्शन स्थापित करे।

यदि आपकी ओपनवीपीएन सुरंगों का उपयोग कर संपीड़ित किया जाता है comp-lzo, तो यह अक्षम करने पर विचार करें, साथ ही, चूंकि परिवहन में पोटैब्लेंटियल लागत बचत ओवरहेड द्वारा पल्ला झुक सकती है।


मैंने आपकी सलाह का पालन किया और http-server-closeHAproxy से विकल्प को हटा दिया और मैंने OpenVPN कॉन्फ़िगरेशन को उपयोग UDPकरने के बजाय बदल दिया TCP। दुर्भाग्य से, मुझे कोई अंतर नहीं दिखता है। यहां जेनकिंस डैशबोर्ड लोड करने का पूरा लॉग है: पेस्ट । पृष्ठ लोड करने में 10.9 मिनट लगते हैं (समाप्त: 10.9 मिनट, DOMContentLoaded: 6.0 मिनट, लोड 10.9 मिनट) क्रोम के अनुसार और HAproxy 6 मिनट दिखाते हैं। जब मैं HAproxy (VPN पर) से अपना बैक-एंड पिंग करता हूं, तो अब मेरे पास 13 ms का एक बहुत ही संगत पिंग है। बैक-एंड के पास पर्याप्त से अधिक संसाधन हैं।
जोएल बोडमैन

इस बीच में मैंने बिना OpenVPN के यह कोशिश की कि HAproxy बैकएंड कॉन्फिगर में वेब सर्वर के सार्वजनिक आईपी पते का उपयोग करके और परिणाम बिल्कुल वैसा ही हो।
जोएल Bodenmann

आपके लॉग सुझाव देते हैं कि दोनों परिवर्तन किए गए थे और अपने इच्छित उद्देश्य को पूरा किया था। दुर्भाग्य से, मुझे अब लॉग में कुछ भी परेशान नहीं दिख रहा है जो सुझाव देता है कि समस्या प्रॉक्सी या बैक-एंड के साथ है ... ब्राउज़र अनुरोधों को जल्दी लोड करने के लिए लगता है, इस कारण से कुछ भी अनुरोध जारी करने से पहले ब्राउज़र इंतजार नहीं करता है। । "जेनकिंस डैशबोर्ड स्लो" को देखते हुए लगता है कि प्रॉक्सी और सुरंग इष्टतम नहीं हो सकते हैं, शुरू में, वे असली मुद्दा नहीं हो सकते हैं।
माइकल - साइक्लबोट

मैं उस विश्लेषण के साथ उंगलियों को इंगित करने की कोशिश नहीं कर रहा हूं ... बस यह सुझाव दे रहा हूं कि लॉग्स से लगता है कि ब्राउज़र बस इस पर इंतजार नहीं कर रहा है, और कुछ और करने में व्यस्त होना चाहिए। पर क्या? इसके अलावा, मैं स्पष्ट नहीं हूँ कि " मूल प्रश्न में नंगे स्थिर HTML सामग्री वेबसर्वर और REST API वेब सेवा" का अर्थ क्या है।
माइकल - sqlbot

खैर, मैंने अब एक नियमित वर्डप्रेस वेबसाइट के साथ यह कोशिश की। जब मैं वेब सर्वर के सामान्य सार्वजनिक आईपी के माध्यम से वर्डप्रेस वेबसाइट का उपयोग करता हूं तो यह एक सेकंड से भी कम समय में लोड हो जाता है। जब मैं HAproxy पर यह करता हूं तो यह 6.9 मिनट क्रोम स्क्रीनशॉट लेता है और यह इसी HAproxy लॉग है: पेस्ट यह मेरा वर्तमान HAproxy कॉन्फिगरेशन है: पेस्ट मुझे विभिन्न अन्य वेबसाइटों के साथ एक ही परिणाम मिलता है।
जोएल बोडेनमैन

0

यह फ़ायरवॉल / NAT विन्यास के साथ एक मुद्दा निकला।

हालाँकि, यदि कोई इस मुद्दे पर आता है, तो HAproxy समुदाय पर कुछ और मदद है: https://discourse.haproxy.org/t/reverse-proxy-very-slow-page-load/2172


यदि उस लिंक पर कुछ भी है जो उपयोगी होगा, तो इसे आपके उत्तर में संपादित किया जाना चाहिए। लिंक समय के साथ खराब होने का एक तरीका है।
माइकल हैम्पटन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.