हम उदाहरण के रूप में fasthttp का उपयोग करके एक उच्च-प्रदर्शन http क्लाइंट लिख रहे हैं। अलेक्जेंडर वाल्याल्किन (वर्टमीडिया)

Fasthttp लाइब्रेरी मानक गोलंग पैकेज से नेट / http के लिए एक त्वरित विकल्प है।
इसकी व्यवस्था कैसे की जाती है? वह इतनी जल्दी क्यों है?

मैं आपके ध्यान में अलेक्जेंडर वाल्याल्किन फास्टहटप क्लाइंट इंटर्नल्स की रिपोर्ट का एक प्रतिलेख लाता हूं।
Fasthttp पैटर्न का उपयोग आपके एप्लिकेशन, आपके कोड को गति देने के लिए किया जा सकता है।

कौन परवाह करता है, बिल्ली में आपका स्वागत है।

मैं अलेक्जेंडर वाल्याल्किन हूं। मैं वर्टमीडिया में काम करता हूं। मैंने अपनी जरूरतों के लिए तेजी से विकास किया। इसमें http क्लाइंट और http सर्वर का कार्यान्वयन शामिल है। Fasthttp नेट गो / http से मानक गो पैकेज से बहुत तेज है।

Fasthttp http सर्वर और क्लाइंट का तेजी से कार्यान्वयन है। Github.com पर fasthttp स्थित है

मुझे लगता है कि कई लोगों ने fasthttp सर्वर के बारे में सुना है, कि यह बहुत तेज है। लेकिन कुछ लोगों ने फास्टटैप क्लाइंट के बारे में सुना है। Fasthttp सर्वर techempower से बेंचमार्क में भाग लेता है - http सर्वर के लिए संकीर्ण सर्कल में प्रसिद्ध बेंचमार्क। Fasthttp सर्वर 12 और 13 के दौर में भाग लेता है। राउंड 13 अभी तक बाहर नहीं आया है (2016 में - लगभग।)।

राउंड 12 के परीक्षणों में से एक का परिणाम, जहां फास्टटैप लगभग सबसे ऊपर है। संख्याएँ बताती हैं कि इस परीक्षा में वह प्रति सेकंड कितने प्रश्न करता है। इस परीक्षण में, हैलो वर्ल्ड लौटाने वाले पेज के लिए एक अनुरोध किया गया है। हैलो वर्ल्ड पर फास्टटैप बहुत तेज है।

अगले दौर के प्रारंभिक परिणाम, जो अभी तक जारी नहीं किए गए हैं (2016 में - लगभग एड।)। 4 फास्टटैप कार्यान्वयन बेंचमार्क में पहला स्थान लेते हैं, जो न केवल हैलो वर्ल्ड देता है, बल्कि यह डेटाबेस में भी क्रॉल करता है और टेम्पलेट के आधार पर एक html पृष्ठ बनाता है।

Fasthttp क्लाइंट के बारे में बहुत कम लोग जानते हैं। लेकिन वास्तव में वह शांत भी है। इस रिपोर्ट में मैं आपको आंतरिक डिवाइस फास्टहट क्लाइंट के बारे में बताऊंगा और इसे क्यों विकसित किया गया।

Fasthttp में वास्तव में कई क्लाइंट हैं: क्लाइंट, होस्टक्लाइंट, और पाइपलाइनलाइन। आगे मैं आपको उनमें से प्रत्येक के बारे में अधिक बताऊंगा।

Fasthttp.Client एक सामान्य सामान्य उद्देश्य http क्लाइंट है। इसके साथ, आप किसी भी इंटरनेट साइट पर अनुरोध कर सकते हैं, उत्तर प्राप्त कर सकते हैं। इसकी विशेषताएं: यह जल्दी से काम करता है, यह नेट / http पैकेज के विपरीत, प्रति होस्ट के खुले कनेक्शन की संख्या को सीमित कर सकता है। प्रलेखन https://godoc.org/github.com/valyala/fasthttp#Client पर है ।

Fasthttp.HostClient केवल एक सर्वर के साथ संचार करने के लिए एक विशेष क्लाइंट है। आमतौर पर इसका इस्तेमाल HTTP API: REST API, JSON API को एक्सेस करने के लिए किया जाता है। यह इंटरनेट से प्रॉक्सी ट्रैफ़िक को कई सर्वरों पर आंतरिक डेटाकेंटर के लिए भी इस्तेमाल किया जा सकता है। प्रलेखन यहाँ है: https://godoc.org/github.com/valyala/fasthttp#HostClient ।

Fasthttp.Client की तरह, Fasthttp.HostClient बैकएंड सर्वर में से प्रत्येक के लिए खुले कनेक्शन की संख्या को सीमित कर सकता है। यह कार्यक्षमता नेट / http में अनुपस्थित है, और यह सुविधा नि: शुल्क नगनेक्स में भी अनुपस्थित है। यह कार्यक्षमता केवल भुगतान किए गए nginx में है, जहाँ तक मुझे पता है।

Fasthttp.PipelineClient एक विशेष क्लाइंट है जो आपको सर्वर के लिए या सीमित संख्या में पाइपलाइन अनुरोधों को प्रबंधित करने की अनुमति देता है। यह HTTP प्रोटोकॉल पर, एपीआई का उपयोग करने के लिए उपयोग किया जा सकता है, जहां आपको बहुत सारे अनुरोध करने और जितनी जल्दी हो सके करने की आवश्यकता है। Fasthttp.PipelineClient की सीमा यह है कि यह हेड ऑफ लाइन ब्लॉकिंग से पीड़ित हो सकता है। यह तब होता है जब हम सर्वर को बहुत सारे अनुरोध भेजते हैं और प्रत्येक अनुरोध के उत्तर की प्रतीक्षा नहीं करते हैं। सर्वर इन अनुरोधों में से एक पर अवरुद्ध है। इस वजह से, उसके बाद आने वाले अन्य सभी अनुरोध तब तक प्रतीक्षा करेंगे जब तक कि यह सर्वर धीमी गति से अनुरोध नहीं करता। Fasthttp.PipelineClient का उपयोग केवल तभी किया जाना चाहिए जब आप सुनिश्चित हों कि सर्वर तुरंत आपके अनुरोधों का जवाब देगा। प्रलेखन ।

अब मैं इनमें से प्रत्येक ग्राहक के आंतरिक कार्यान्वयन के बारे में बात करना शुरू करूँगा। मैं Fasthttp.HostClient से शुरू करूंगा, क्योंकि लगभग सभी अन्य क्लाइंट इसके आधार पर बने हैं।

यह गो पर छद्म कोड में HTTP क्लाइंट का सबसे सरल कार्यान्वयन है। हम जुड़े हुए हैं, हमें इस URL पर http प्रतिक्रिया मिलती है। हम इस मेजबान से जुड़ रहे हैं। हमें कनेक्शन मिलता है। इस कोड में, ताकि यह वॉल्यूम से कम हो, सभी त्रुटि जांच गायब हैं। वास्तव में, ऐसा नहीं है। आपको हमेशा त्रुटियों की जांच करनी चाहिए। एक कनेक्शन बनाएँ। डेफर के साथ निकट संबंध। हम URL द्वारा इस कनेक्शन के लिए एक अनुरोध भेजते हैं। हमें उत्तर मिलता है, हम इस उत्तर को वापस करते हैं। इस HTTP क्लाइंट कार्यान्वयन में क्या गलत है?

पहली समस्या यह है कि इस कार्यान्वयन में, प्रत्येक अनुरोध के लिए कनेक्शन स्थापित किया गया है। यह कार्यान्वयन HTTP KeepAlive का समर्थन नहीं करता है। इस समस्या को कैसे हल करें? आप प्रत्येक सर्वर के लिए कनेक्शन पूल का उपयोग कर सकते हैं। आप सभी सर्वरों के लिए कनेक्शन पूल का उपयोग नहीं कर सकते, क्योंकि अगला अनुरोध स्पष्ट नहीं है कि किस सर्वर को भेजना है। प्रत्येक सर्वर का अपना कनेक्शन पूल होना चाहिए। और हम HTTP KeepAlive का उपयोग करते हैं। इसका मतलब है कि कनेक्शन हैडर को कनेक्शन बंद निर्दिष्ट करने की आवश्यकता नहीं है। HTTP / 1.1 में, डिफ़ॉल्ट रूप से HTTP KeepAlive के लिए समर्थन है और हैडर से कनेक्शन बंद करना होगा। यहाँ कनेक्शन पूल समर्थन के साथ क्लाइंट छद्म कोड में कार्यान्वयन है। प्रत्येक होस्ट के लिए कई कनेक्शन पूल का एक सेट है। पहला फ़ंक्शन, conPoolForHost, दिए गए URL से होस्ट के लिए कनेक्शन पूल लौटाता है। तब हमें इस कनेक्शन पूल से कनेक्शन मिलता है, हम इस कनेक्शन को पूल में वापस भेजने के लिए Defer का उपयोग करते हैं, इस कनेक्शन के लिए एक KeepAlive अनुरोध भेजें, और प्रतिक्रिया दें। प्रतिक्रिया के बाद, Defer को निष्पादित किया जाता है और पूल में कनेक्शन लौटता है। इस प्रकार, हम HTTP KeepAlive समर्थन को सक्षम करते हैं और सब कुछ तेजी से काम करना शुरू कर देता है। क्योंकि हम प्रत्येक अनुरोध के लिए कनेक्शन बनाने में समय बर्बाद नहीं करते हैं।

लेकिन समाधान में भी समस्याएं हैं। यदि आप फ़ंक्शन के हस्ताक्षर को देखते हैं, तो आप देख सकते हैं कि यह प्रत्येक अनुरोध के लिए एक प्रतिक्रिया वस्तु देता है। इसका मतलब है कि इस ऑब्जेक्ट के लिए आपको प्रत्येक बार मेमोरी आवंटित करने की आवश्यकता है, इसे इनिशियलाइज़ करें और इसे वापस लौटा दें। यह प्रदर्शन के लिए बुरा है। यह बहुत बुरा हो सकता है यदि आपके पास बहुत सारे ऐसे कॉल हैं जो फ़ंक्शन प्राप्त करते हैं।

इसलिए, इस समस्या को हल किया जा सकता है क्योंकि इस फ़ंक्शन के मापदंडों में प्रतिक्रिया ऑब्जेक्ट पर पॉइंटर ऑब्जेक्ट रखकर फास्टहेटप में हल किया गया है। इस तरह, वह कॉलिंग कोड इस प्रतिक्रिया ऑब्जेक्ट को कई बार पुन: उपयोग कर सकता है। स्लाइड पर इस विचार का कार्यान्वयन है। हम प्राप्त फ़ंक्शन के लिए प्रतिक्रिया ऑब्जेक्ट का संदर्भ पास करते हैं - और फ़ंक्शन इस प्रतिक्रिया को भरता है। अंतिम पंक्ति इस ऑब्जेक्ट को भरती है।

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

तीसरी समस्या है कनेक्शन के करीब। कनेक्शन बंद - HTTP हेडर, जो अनुरोध और प्रतिक्रिया दोनों में पाया जा सकता है। यदि हमें ऐसा हेडर मिला है, तो यह कनेक्शन बंद होना चाहिए। इसलिए, क्लाइंट के कार्यान्वयन में, कनेक्शन को बंद करने के लिए प्रदान करना अनिवार्य है। यदि आपने हेडर कनेक्शन के साथ एक अनुरोध भेजा है, तो प्रतिक्रिया प्राप्त करने के बाद आपको इस कनेक्शन को बंद करने की आवश्यकता है। यदि आपने कनेक्शन बंद किए बिना अनुरोध भेजा है, और आपने कनेक्शन के साथ प्रतिक्रिया वापस कर दी है, तो प्रतिक्रिया प्राप्त करने के बाद आपको इस कनेक्शन को बंद करने की भी आवश्यकता है।

इस कार्यान्वयन के लिए छद्म कोड यहां दिया गया है। आपके द्वारा प्रतिक्रिया प्राप्त करने के बाद, हम जांचते हैं कि क्या कनेक्शन क्लोज हेडर वहीं स्थापित है। यदि स्थापित है, तो बस कनेक्शन बंद करें। यदि स्थापित नहीं है, तो पूल में वापस कनेक्शन लौटाएं। यदि ऐसा नहीं किया जाता है, तो यदि सर्वर जवाब देने के बाद कनेक्शन बंद कर देता है, तो आपके कनेक्शन पूल में सर्वर बंद होने वाले टूटे हुए कनेक्शन होंगे, और आप उनमें कुछ लिखने की कोशिश करेंगे और आपको त्रुटियाँ मिलेंगी।

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

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

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

दूसरा समाधान, जो पहले पूरक है, सर्वर से कनेक्शन पर टाइमआउट सेट करना है। यदि सर्वर लंबे समय तक प्रतिक्रिया नहीं करता है या नेटवर्क डाउन है, तो यह प्राप्त फ़ंक्शन को अनलॉक करेगा।

यदि समाधान # 1 में नेटवर्क काम नहीं करता है, तो सब कुछ लटका होगा। जब हमने cuncurrency को सीमित संख्या में goroutines टाइप किया, जो यहां लटका हुआ है, गेटाइमआउट फ़ंक्शन हमेशा एक त्रुटि लौटाएगा। सामान्य रूप से काम करना शुरू करने के लिए, आपको दूसरे समाधान (समाधान # 2) की आवश्यकता होती है, जो कनेक्शन से पढ़ने और लिखने के लिए एक समय सीमा निर्धारित करता है। यदि नेटवर्क या सर्वर काम करना बंद कर देता है तो यह अवरुद्ध गोरोनाइट को अनलॉक करने में मदद करता है।

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

प्रतिक्रिया प्रतिलिपि बनाकर और प्रतिक्रिया प्रतिलिपि गोरोइन को पास करके समस्या का समाधान किया जाता है। गेट पूरा होने के बाद, इस प्रतिक्रिया से प्रतिक्रिया को हमारी मूल प्रतिक्रिया में कॉपी करें, जिसे यहां से पारित किया गया है। इस प्रकार, डेटा दौड़ हल हो गई है। प्रतिक्रिया की यह प्रतिलिपि थोड़े समय के लिए रहती है और वापस पूल में लौट आती है। हम प्रतिक्रिया का पुन: उपयोग करते हैं। एक प्रतिक्रिया प्रतिलिपि केवल टाइमआउट द्वारा पूल में फिट नहीं हो सकती है। टाइमआउट तक, पूल से प्रतिक्रिया का नुकसान होता है।

क्या सर्वर द्वारा टाइमआउट के भीतर प्रतिक्रिया नहीं देने के बाद मुझे कनेक्शन बंद करने की आवश्यकता है? जवाब है नहीं। बल्कि, हाँ, यदि आप सर्वर का बैकअप लेना चाहते हैं। क्योंकि जब आप सर्वर को अनुरोध भेजते हैं, तो कुछ समय तक प्रतीक्षा करें, सर्वर इस समय के दौरान प्रतिक्रिया नहीं करता है - यह अनुरोधों का सामना नहीं करता है। उदाहरण के लिए, आप इस कनेक्शन को बंद करते हैं, लेकिन इसका मतलब यह नहीं है कि सर्वर तुरंत इस अनुरोध को निष्पादित करना बंद कर देगा। सर्वर इसे निष्पादित करना जारी रखेगा। सर्वर यह पता लगाएगा कि इस अनुरोध को निष्पादित करने की आवश्यकता नहीं है क्योंकि यह आपको प्रतिक्रिया देने की कोशिश करता है। आपने कनेक्शन बंद कर दिया, फिर से नया अनुरोध बनाने का प्रयास किया, फिर से समय समाप्त हो गया, फिर से बंद हुआ, एक नया अनुरोध बनाया गया। आप सर्वर वृद्धि पर एक लोड होगा। नतीजतन, आपकी सेवा आपके अनुरोधों पर निर्भर करती है। ये HTTP अनुरोधों के स्तर पर DoS हैं। यदि आपके पास सर्वर हैं जो धीरे-धीरे चल रहे हैं, और आप उन्हें वापस नहीं करना चाहते हैं, तो आपको टाइमआउट के बाद कनेक्शन बंद करने की आवश्यकता नहीं है। आपको थोड़ी देर इंतजार करने की आवश्यकता है, इस सर्वर के प्रायश्चित के लिए कनेक्शन छोड़ दें। उसे आपको जवाब देने की कोशिश करने दें। इस बीच, अन्य मुफ्त कनेक्शन का उपयोग करें। इससे पहले जो कुछ बताया गया था, वह Fasthttp.Client के कार्यान्वयन के सभी चरणों और Fasthttp.Client के कार्यान्वयन के दौरान होने वाली समस्याओं के बारे में है। इन समस्याओं को Fasthttp.HostClient में हल किया गया है।

अब हमारे पास एक तेज़ ग्राहक है? वास्तव में नहीं। आपको यह देखना होगा कि कनेक्शन पूल कैसे लागू किया जाता है।

कनेक्शन पूल का भोली कार्यान्वयन इस तरह दिखता है। कुछ प्रकार का सर्वर पता है जहां आपको कनेक्शन स्थापित करने की आवश्यकता है। इस सूची तक पहुंच को सिंक्रनाइज़ करने के लिए मुफ्त कनेक्शन और लॉक की एक सूची है।

यहाँ कनेक्शन पूल से कनेक्शन प्राप्त करने का कार्य है। हम अपने संग्रह की एक सूची देख रहे हैं। अगर वहां कुछ है, तो हम एक मुफ्त कनेक्शन प्राप्त करते हैं और इसे वापस करते हैं। यदि कुछ नहीं है, तो इस सर्वर से एक नया कनेक्शन बनाएं और उसे वापस लौटा दें। यहाँ क्या गलत है?

ConPool.Put फ़ंक्शन एक मुफ्त कनेक्शन देता है।

टाइमआउट खाते में। Fasthttp.Client में, आप एक खुले अप्रयुक्त कनेक्शन के अधिकतम जीवनकाल को निर्दिष्ट कर सकते हैं। यह समय बीत जाने के बाद, अप्रयुक्त कनेक्शन स्वचालित रूप से बंद हो जाते हैं और इस पूल से बाहर फेंक दिए जाते हैं।

पुराने कनेक्शन समय के साथ अप्रयुक्त हो जाते हैं और स्वचालित रूप से बंद हो जाते हैं और पूल से हटा दिए जाते हैं।

जब कनेक्शन पूल से लिया जाता है, और यह पता चलता है कि उसका सर्वर बंद था, और आपने वहां कुछ लिखने की कोशिश की, तो एक दूसरा प्रयास किया जाता है - एक नया कनेक्शन प्राप्त होता है और इस कनेक्शन के लिए फिर से अनुरोध भेजने का प्रयास करता है। लेकिन यह केवल तभी होता है जब यह अनुरोध उदासीन होता है - अर्थात, ऐसा अनुरोध जिसे सर्वर पर साइड इफेक्ट्स के बिना कई बार निष्पादित किया जा सकता है - क्या यह एक GET या HEAD अनुरोध है। उदाहरण के लिए, मानक नेट / http में अभी हमने बंद कनेक्शनों के लिए एक चेक जोड़ा। वहाँ उन्होंने एक पेचीदा जाँच की। वे जांच करते हैं, जब वे पूल से कनेक्शन के लिए एक नया अनुरोध भेजने का प्रयास करते हैं, अगर कम से कम एक बाइट इस कनेक्शन पर भेजा जाता है। यदि सेट किया गया है, तो त्रुटि वापस करें। यदि आपने छुट्टी नहीं ली है, तो हम पूल से एक नया कनेक्शन लेते हैं।

पूल में क्या गलत है? इसका आकार सीमित नहीं है। नेट / http के समान कार्यान्वयन। यदि आप एक क्लाइंट को लिखते हैं जो लाखों गोरोइंट्स से एक स्लो सर्वर पर ब्रेक कर रहा है, तो क्लाइंट इस सर्वर से एक मिलियन कनेक्शन बनाने की कोशिश करेगा। मानक नेट / http पैकेज में कनेक्शन की अधिकतम संख्या की कोई सीमा नहीं है। HTTP पर API का उपयोग करने वाले क्लाइंट के लिए, इस कनेक्शन पूल के आकार को सीमित करना उचित है। अन्यथा, आपके ग्राहक नीचे जा सकते हैं, क्योंकि आप सभी संसाधनों का उपयोग करेंगे: थ्रेड्स, ऑब्जेक्ट्स, कनेक्शन, गोरोएंटाइन और मेमोरी। इसके अलावा, यह आपके सर्वर के डीओएस को जन्म दे सकता है, क्योंकि बहुत सारे कनेक्शन उनके लिए स्थापित किए जाएंगे, जो या तो उपयोग नहीं किए जाते हैं या अक्षम रूप से उपयोग किए जाते हैं, क्योंकि सर्वर इतना कनेक्शन नहीं पकड़ सकता है।

कनेक्शन पूल को सीमित करें। कोड यहां नहीं है, क्योंकि यह एक स्लाइड पर फिट होने के लिए बहुत बड़ा है। इच्छुक लोग इस फ़ंक्शन के कार्यान्वयन को github.com पर देख सकते हैं।

दूसरी समस्या। क्लाइंट के लिए बहुत सारे अनुरोध किसी समय पर आते हैं। और उसके बाद अनुरोधों की पिछली संख्या में गिरावट और वापसी होती है। उदाहरण के लिए, 10,000 अनुरोध एक साथ पहुंचे, फिर अनुरोधों की संख्या 1000 प्रति यूनिट समय पर वापस आ गई। उसके बाद, कनेक्शन पूल 10000 कनेक्शन तक बढ़ जाएगा। ये कनेक्शन अंतहीन रूप से लटका रहेगा। यह समस्या 1.7 संस्करण से पहले मानक नेट / http क्लाइंट में थी। इसलिए, आपको इस समस्या को हल करने की आवश्यकता है।

इस समस्या का उपयोग अप्रयुक्त कनेक्शन के जीवन को सीमित करके किया जाता है। यदि कुछ समय के लिए कनेक्शन के माध्यम से एक भी अनुरोध नहीं भेजा गया था, तो यह बस बंद हो जाता है और पूल से बाहर निकाल दिया जाता है। कोई कार्यान्वयन नहीं है क्योंकि यह बहुत बड़ा है।

हमें एक ग्राहक मिला जो तेजी से और ठंडा काम करता है? वास्तव में ऐसा नहीं है। हमारे पास अभी भी कनेक्शन बनाने का कार्य है - डायलहॉस्ट।

आइए इसके कार्यान्वयन को देखें। एक भोली कार्यान्वयन इस तरह दिखता है। वह पता जहां आप कनेक्ट करना चाहते हैं बस प्रेषित है। हम मानक फ़ंक्शन को नेट कहते हैं। वह कनेक्शन लौटाती है। इस कार्यान्वयन में क्या गलत है?

डिफ़ॉल्ट रूप से, net.Dial प्रत्येक कॉल के लिए dns अनुरोध करता है। इससे आपके DNS सबसिस्टम के संसाधनों का उपयोग बढ़ सकता है। यदि API क्लाइंट सर्वर से कनेक्ट रहते हैं जो KeepAlive कनेक्शन का समर्थन नहीं करते हैं, तो वे कनेक्शन बंद कर देते हैं। आप KeepAlive द्वारा समर्थित हैं, और सर्वर नहीं हैं। ऐसी प्रतिक्रिया के बाद, सर्वर कनेक्शन बंद कर देता है। यह पता चला है कि net.Dial को हर अनुरोध पर बुलाया जाता है। प्रति सेकंड लगभग 10 हजार ऐसे अनुरोध हैं। आप प्रति सेकंड 10 हजार बार डीएनएस में हल करते हैं। यह DNS सबसिस्टम को लोड करता है।

इस समस्या को कैसे हल करें? कैश बनाएं जो मैप-इट को थोड़े समय के लिए सीधे आपके गो कोड में होस्ट करता है, और प्रत्येक नेटियल पर हल करने वाले डीएनएस को कॉल न करें। तैयार आईपी पते से कनेक्ट करें।

दूसरी समस्या सर्वर पर असमान लोड है यदि आपके पास डोमेन नाम के पीछे कई सर्वर छिपे हुए हैं। उदाहरण के लिए, राउंड रॉबिन डीएनएस की तरह। यदि आप DNS में एक आईपी पते को थोड़ी देर के लिए कैश करते हैं, तो इस समय के दौरान आपके सभी अनुरोध एक सर्वर पर जाएंगे। यद्यपि आपके पास उनमें से कई हो सकते हैं। इस समस्या को हल करना आवश्यक है। यह सभी उपलब्ध IP की गणना करके हल किया जाता है जो किसी दिए गए डोमेन नाम के पीछे छिपे होते हैं। यह भी Fasthttp.Client में किया गया है।

तीसरी समस्या यह है कि net.Dial नेटवर्क या सर्वर की समस्याओं के कारण अनिश्चित काल तक लटका रह सकता है जहां आप कनेक्ट करने का प्रयास कर रहे हैं। इस स्थिति में, आपके गोरआउट्स गेट फ़ंक्शन पर लटकाए जाएंगे। इससे संसाधनों का उपयोग भी बढ़ सकता है।

समाधान एक टाइमआउट जोड़ना है। Dial package net. , , . , , , .

. Get Dial . - . Dial , , . , , . DialTimeout. , .

HostClient .

HostClient , . LoadBalance.

HostClient . , HostClient . connection . . .

Fauly host .

— . Dial. , Dial. Get, , - . , . , , .

— . Get , . , , , .

Error , Round Robin .

SSL , Golang . .

fasthttp.Client. HostClient, fasthttp.Client HostClient.

Get. HostClient . HostClient . HostClient Get. HostClient.

HostClient - , URL. web-crawling ( ), . HostClient . net/http, . , HostClient, . fasthttp.

Client HostClient, PipelineClient . PipelineClient connection pool. PipelineClient connection, . PipelineClient connection. connection pool. PipelineClient connection .

PipelineClient connection . PipelineConnClient.writer — connection, . PipelineConnClient.reader — connection , PipelineConnClient.writer. PipelineConnClient.reader , Get.

PipelineClient.Get PipelineClient. pipelineWork url, , response, channel done, response.

Get. C . channel, PipelineConnClient.writer connection. channel w.done, PipelineConnClient.reader, response request.

net/http fasthttp.Client 2 .

, , fasthttp. , , . fasthttp. , fasthttp, . allocation . .

net/http. , allocation net/nttp. .

: PipelineClient connection?

: — pending , . . request, pending , Error.

: API , fasthttp, net/http?

: . net/http . . string -, string . , net/http, . - , . fasthttp , . . net/http fasthttp , net/http POST-, response, () . fasthttp , request response . 10 request 10 response . , . fasthttp 10 request 10 response? . — . , net/http. . , net/http — .

PS .

.

— .