जिंदा रखने के रास्ते पर रेक

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

यह कहानी एक गलती से शुरू होती है। किसी तरह हमने लोड परीक्षण किया, जिसका मुख्य तत्व बड़ी संख्या में लघु http अनुरोधों का निष्पादन था। नेटकोर 2.2 के तहत लिखा गया एक क्लाइंट , जो किसी बिंदु पर शुरू होता है, एक System.Net.Sockets.SocketException को फेंकता है : उपयोग में पहले से ही पता । यह जल्दी से स्पष्ट हो गया कि बंदरगाहों के पास क्लाइंट को खाली करने का समय नहीं था, और कुछ बिंदु पर सिस्टम को एक नया खोलने से मना कर दिया गया था। अब, यदि हम कोड पर जाते हैं, तो समस्या HttpWebRequest वर्ग और निर्माण के साथ पुराने दृष्टिकोण का उपयोग करने में थी :

var request = WebRequest.CreateHttp(uri);
using(var resp = request.GetResponse()){ … }

ऐसा लगता है कि हम संसाधन जारी कर रहे हैं, और बंदरगाह को समय पर जारी किया जाना चाहिए। हालांकि, नेटस्टैट ने TIME_WAIT राज्य में बंदरगाहों की संख्या में तेजी से वृद्धि का संकेत दिया। इस राज्य का अर्थ है कनेक्शन बंद होने का इंतजार करना (और संभवतः खोए हुए डेटा को प्राप्त करना)। नतीजतन, पोर्ट 1-2 मिनट के लिए इसमें हो सकता है। यह समस्या कई लेख (में कुछ विस्तार से चर्चा की है TIME_WAIT कतार के साथ कोई समस्या , TIME_WAIT के बारे में इतिहास )। फिर भी, इसका मतलब है कि डॉटनेट "ईमानदारी से" कनेक्शन को बंद करने की कोशिश कर रहा है, और आगे सिस्टम में टाइमआउट सेटिंग्स की गलती के माध्यम से पहले से ही होता है।

ऐसा क्यों हो रहा है और इससे कैसे निपटना है

मैं जिंदा रखने की बात नहीं करूंगा । आप इसके बारे में खुद पढ़ सकते हैं। लेख का उद्देश्य रेक के चारों ओर जाने की कोशिश करना है, ध्यान से डेवलपर के मार्ग पर रखा गया है। Msdn के अनुसार , HttpWebRequest वर्ग की KeepAlive संपत्ति डिफ़ॉल्ट रूप से सत्य है । यही है, यह सब समय, HttpWebRequest ने सर्वर को "धोखा" दिया, उसे एक कनेक्शन बनाए रखने के लिए कहा, जिसके बाद वह खुद इसे तोड़ देगा। अधिक सटीक होने के लिए, डिफ़ॉल्ट सेटिंग्स के साथ HttpWebRequest ने "कनेक्शन: रखने-जीवित" शीर्ष लेख नहीं भेजा, बस यह मोड HTTP / 1.1 मानक में निहित है। पहली कोशिश करने के लिए KeepAlive को जबरदस्ती अक्षम करना था। यदि आप HttpWebRequest.KeepAlive = false सेट करते हैं, तो अनुरोध में हेडर "कनेक्शन: करीब" दिखाई देता है। जाहिर है, इसने पूरी तरह से परीक्षण बेंच पर समस्या को हल किया। सर्वर के रूप में, nginx को एक स्थिर पृष्ठ के साथ कॉन्फ़िगर किया गया था।

निम्नलिखित कोड का परीक्षण किया गया था:

while (true)
{
  var request = WebRequest.CreateHttp(uri);
  request.KeepAlive = false;
  var resp = await request.GetResponseAsync();
  using (var sr = new StreamReader(resp.GetResponseStream()))
  {
    var content = sr.ReadToEnd();
  }
}

हालांकि, जब सर्वर हार्डवेयर पर शुरू करने की कोशिश की जा रही है, तो भारी लोड (प्रति सेकंड 1000 से अधिक अनुरोध) के तहत, यह कोड फिर से उसी त्रुटियों का उत्पादन करने लगा। केवल अब पोर्ट CLOSE_WAIT, LAST_ACK स्थिति में थे। ये कनेक्शन के पूर्व-अंतिम समापन राज्य होते हैं जब ग्राहक क्लोजर के सर्जक से पुष्टि की प्रतीक्षा करता है। इस तरह के व्यवहार से संकेत मिलता है कि ग्राहक नए खुले कनेक्शन के साथ "चोक" करने लगता है।

बंद न करें, पुन: उपयोग करें

, , . keep-alive HttpClient. .

, , ? keep-alive nginx:

• keepalive_timeout – ( 15)
• keepalive_requests – ( 100)

netstat wireshark, . keepalive_requests (> 1000) , .

http , . . , , keep-alive. keep-alive , .

:

• RunHttpClient – HttpClient "Connection: keep-alive"
• RunHttpClientClosed – HttpClient "Connection: closed"
• RunWebRequestClosed - वर्ग HttpWebRequest मोड "कनेक्शन: बंद" का उपयोग करता है

Nginx सर्वर को निम्नलिखित मापदंडों से कॉन्फ़िगर किया गया है:

• Keepalive_timeout 60s;
• Keepalive_requests 100000;