जब एएसपी.नेट को अनुरोध प्राप्त होता है, तो यह कैसे निर्धारित करता है कि इसे सेवा देना है या कतारबद्ध करना है या नहीं? मैं पूछता हूं क्योंकि मैं सर्वर पर प्रदर्शन काउंटरों की निगरानी कर रहा हूं और सीपीयू अधिकतम नहीं हुआ है और उपलब्ध वर्कर थ्रेड का एक बोतलबंद है, लेकिन मैं अब भी 200 अनुरोधों को कतारबद्ध कर रहा हूं।ASP.NET कैसे निर्धारित करता है कि कोई अनुरोध कतारबद्ध है या नहीं?
मैं अनुसंधान कर रहा हूँ और मेरा मानना है कि मैं एक स्वीकार्य जवाब पर आ गए हैं। मेरा प्राथमिक स्रोत यह आलेख है: http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx
जैसा कि मैं समझता हूं कि अनुरोध प्रक्रिया को दो मुख्य तरीके से थ्रॉटल किया जाता है। पहला MaxConcurrentRequestsPerCPU प्रॉपर्टी है। .NET 4 से पहले यह डिफ़ॉल्ट रूप से 12 पर सेट किया गया था। .NET 4 में इसे 5000 में बदल दिया गया था। एसिंक अनुरोधों के लिए वे बहुत कुछ अनुमति देना चाहते थे, और सिंक्रोनस अनुरोधों के लिए उनका मानना है कि एएसपी.नेट थ्रेडपूल सिंक्रोनस अनुरोधों को काफी अच्छी तरह से थ्रॉटल करेगा। दूसरा कोर्स थ्रेडपूल ही है। एएसपी.नेट के अनुरोध के बाद वहां यह तय हो सकता है कि यह कब होगा।
यदि आप एसिंक प्रोसेसिंग कर रहे हैं, तो आपके सीमित कारक CPU, नेटवर्क और डिस्क होने की संभावना है और कोई भी एएसपी.NET अनुरोध थ्रॉटलिंग नहीं है। यह संभवतः MaxConcurrentRequestsPerCPU सीमा को हिट कर सकता है, लेकिन वह सीमा वास्तव में उच्च है।
यदि आप लंबी अवधि के लिए वेब कॉल पर सिंक्रोनस प्रोसेसिंग और अवरुद्ध कर रहे हैं, तो यह अधिक संभावना है कि आप इन सीमाओं में भाग लें। MaxConcurrentRequestsPerCPU .NET 4 से पहले देखने के लिए कुछ है लेकिन अभी भी थ्रेडपूल है।
निष्पादन परीक्षण
मैं एक साथ एक साधारण परीक्षण डाल देखने के लिए कि यह कैसे थ्रॉटलिंग काम किया। मेरे पास 500ms थ्रेड के साथ एक साधारण पृष्ठ है। नींद() कॉल। एक मेजबान मशीन 800 एक साथ एसिंक अनुरोध करता है और एएसपी.NET चलाने वाली एक कार्यकर्ता मशीन उन सभी को संसाधित करती है। परिणाम दिलचस्प थे:
.NET 3.5, कोई संशोधन नहीं: 46 सेकंड्स। प्रक्रिया एक्सप्लोरर के साथ 9 कार्यकर्ता धागे देखा।
.NET 3.5, MaxConcurrentRequestsPerCPU के साथ 5000: 46 सेकंड पर सेट किया गया है। 9 कार्यकर्ता धागे।
.NET 4: 42 सेकंड, या गर्म चलते समय 13 सेकंड। लगभग 35 कार्यकर्ता धागे धीरे-धीरे बनाए जाते हैं।
.NET 4, async: 3 सेकंड
कुछ टिप्पणियों:
+1 पढ़ने योग्य है, धन्यवाद –
यह एक दिलचस्प परिणाम है, लेकिन आपको इसे सर्वर ओएस पर चलाना चाहिए। जाहिर है, आपने इसे क्लाइंट ओएस (जैसे कि विंडोज 7) पर चलाया क्योंकि आप 10 समवर्ती अनुरोधों की सीमा में भाग गए थे। आईआईएस में सर्वर ओएस पर यह सीमा नहीं है। – Flavien
आपने यह कैसे निर्धारित किया कि मैंने "10 समवर्ती अनुरोधों की सीमा में भाग लिया"? अगर ऐसा होता, तो मेरे .NET 4 परीक्षण में 800 अनुरोधों को संसाधित करने में केवल 3 सेकंड क्यों लगे? क्या आप किसी भी दस्तावेज से लिंक कर सकते हैं जो बताता है कि वास्तव में गैर-सर्वर ओएस पर 10 समवर्ती अनुरोधों की सीमा है? – RandomEngy
आईआईएस क्यूईइंग अनुरोध शुरू करने से पहले सभी उपलब्ध थ्रेड का उपयोग नहीं करता है, क्योंकि इन थ्रेडों को अतिरिक्त थ्रेड की आवश्यकता होने पर उपलब्ध होने के लिए इन धागे को उपलब्ध रहने की आवश्यकता है। आईआईएस को निष्पादन निष्पादन को वरीयता देने के लिए अनुकूलित किया गया है, और यह नहीं चाहता कि निष्पादन अनुरोध अवरुद्ध हो क्योंकि कार्यकर्ता प्रक्रिया उपलब्ध थ्रेड से बाहर हो गई।
डिफ़ॉल्ट अधिकतम थ्रेड पूल 20, न्यूनतम 8 के साथ, जिसका अर्थ है कि सिस्टम केवल नए अनुरोधों को कतारबद्ध करने से पहले 12 अनुरोधों पर निष्पादित करेगा। अधिकतम थ्रेड को कोर की संख्या से गुणा किया जाता है, लेकिन न्यूनतम धागे नहीं होते हैं, ताकि डिफ़ॉल्ट कतार से पहले दोहरी कोर बॉक्स पर 32 अनुरोधों को अनुमति दे सके।
और सीपीयू शेष होने के कारण, एएसपी.नेट उस पर नजर रखता नहीं है। यह पूरी तरह से उपयोग में धागे की संख्या के बारे में है। उन धागे को डिस्क एक्सेस द्वारा अवरुद्ध किया जा सकता है, डीबी परिणामों को स्थानांतरित करने के लिए नेटवर्क पहुंच, या बस एक थ्रेड। नींद, जो सीपीयू को अधिकतम नहीं होने के बावजूद कतार में जाने वाले नए अनुरोधों में योगदान देगा।
अधिक जानकारी एमएस पैटर्न & प्रदर्शन पर प्रैक्टिस बुक में उपलब्ध है। यह आईआईएस 6/.NET 1.1 पर लागू होता है, लेकिन अवधारणाएं अभी भी बनी हुई हैं। http://msdn.microsoft.com/en-us/library/ff647787.aspx#scalenetchapt06_topic8
IIS7/नेट के लिए 2 + को फिर से कॉन्फ़िगर: http://msdn.microsoft.com/en-us/library/e1f13641.aspx
मैं थ्रेडपूल (http://msdn.microsoft.com/en-us/library/system.threading.threadpool.aspx) पर प्रलेखन पढ़ रहा हूं ".NET Framework संस्करण 4 के साथ शुरुआत, थ्रेड पूल का डिफ़ॉल्ट आकार एक प्रक्रिया के लिए वर्चुअल एड्रेस स्पेस के आकार जैसे कई कारकों पर निर्भर करता है। एक प्रक्रिया थ्रेड की संख्या निर्धारित करने के लिए GetMaxThreads विधि को कॉल कर सकती है। " - यह मेरे लिए 400 लौट रहा है। – RandomEngy
मुझे संदेह है कि यह धागे के बोतलबंद का उपयोग नहीं करेगा, क्योंकि यह आपके प्रदर्शन में जरूरी नहीं है। अधिकतम perf के लिए इसे ज्यादातर थ्रेड के 1: 1 अनुपात का उपयोग करने के लिए पसंद नहीं किया जाता है। एएसपी .NET आंतरिक –
के बारे में निश्चित नहीं है धागे I/O संचालन पर अवरुद्ध कर रहे हैं। इस मामले में उन्हें 1: 1 रखने के साथ CPUs थ्रूपुट की सहायता नहीं करता है। और मुझे नहीं लगता कि एएसपी.नेट यह मान लेगा कि अनुरोध सीपीयू बाध्य हैं। इसके अलावा मैं एक साथ अनुरोध 20 तक जाता हूं, जो मशीन पर प्रोसेसर की संख्या से अधिक है। – RandomEngy
@RandomEnergy: यही कारण है कि मैंने 'ज्यादातर' कहा, और यदि वे I/O संचालन पर अवरुद्ध कर रहे हैं, तो वे ** ** अवरुद्ध कर रहे हैं, जिसका अर्थ है कि उन्हें इसके लिए इंतजार करना होगा, अगर थ्रेड उस पर स्विच नहीं किया गया है पल, यह सीपीयू बर्बाद कर देगा। एक गैर-अवरुद्ध I/O ऑपरेशन, अन्य धागे को CPU लेने की अनुमति देगा, जबकि I/O किया जा रहा है। –