BeginProcessRequest() में क्या होता है?

Question

हम सर्वर-साइड एप्लिकेशन निशान प्रदान करने के लिए न्यूरेलिक का उपयोग कर रहे हैं।

हमने देखा है कि हमारे कुछ अनुप्रयोग लगातार System.Web.Mvc.MvcHandler.BeginProcessRequest() विधि में लगभग 100ms खर्च करते हैं।

यह किसी भी कस्टम नियंत्रक कोड (जिसे अलग से लॉग किया गया है, और संचयी रूप से लॉग नहीं किया गया है) से पहले ऐसा होता है - यह स्पष्ट नहीं है कि यह इस विधि में इतना समय क्यों खर्च करेगा।

इस विधि में एमवीसी किस तरह की चीजें करेगा? क्या यह बस क्यूइंग का अनुरोध कर सकता है?

[संपादित करें:] संदिग्ध के रूप में - नीचे स्केलियर का उत्तर स्पॉट-ऑन था। हम & दूर अनुकूलित हमारे सभी सत्र निर्भरता को हटा दिया, और आवेदन scalability में भारी वृद्धि & स्थिरता देखा

Answer 1

आप जो देख जा सकता है आमतौर पर .NET में धागा चपलता के रूप में जाना जाता है।

जो आप शायद सामयिक लेबल के नीचे के परिणाम के रूप में देख रहे हैं (यानी System.Web.HttpApplication.BeginRequest() में आवेदन कोड) एक थ्रेड चपलता समस्या है; ज्यादातर मामलों में जब आप यहां देखते हैं तो कोड को निष्पादित नहीं किया जाता है, लेकिन वेब संदर्भ पाठकों के लिए पाठक-लेखक लॉक से वापस रिलीज़ होने की प्रतीक्षा करता है।

Application_BeginRequest() "रोकें" एक एएसपी.NET वेब स्टैक में बहुत व्यापक है। सामान्य रूप से जब आप BeginRequest में लंबे समय तक लोड देखते हैं, तो आप एएसपी.NET थ्रेड चपलता और/या थ्रेड लॉक से निपट रहे हैं - खासकर जब आईओ और सत्र आधारित संचालन से निपटते हैं। यह नहीं कि यह एक बुरी बात है, यह सिर्फ यह है कि नेट कैसे सुनिश्चित करता है कि आपके धागे समवर्ती रहते हैं।

टाइम अंतर आमतौर पर BeginRequest और PreRequestHandlerExecute के बीच होता है। यदि एप्लिकेशन सत्र में कई चीजें लिख रहा है तो एएसपी.नेट HttpContext.Current.Session पर एक पाठक-लेखक लॉक जारी करेगा।

यह देखने का एक अच्छा तरीका है कि यह एक मुद्दा है जिसे आप सामना कर रहे हैं, यह देखने के लिए थ्रेड आईडी जांचना होगा कि चपलता एक मुद्दा है या नहीं - आईडी किसी दिए गए अनुरोध के लिए अलग होंगी।

उदाहरण के लिए। डीबगिंग, शायद आप जोड़ सकते हैं जबकि अपने Global.asax.cs के लिए निम्न:

protected void Application_BeginRequest(Object sender, EventArgs e) { 
     Debug.WriteLine("BeginRequest_" + Thread.CurrentThread.ManagedThreadId.ToString()); 
    } 

डिबग आउटपुट विंडो खोलें (विजुअल स्टूडियो से: लटकती "से शो उत्पादन" देखें >> आउटपुट से, फिर "डीबग" का चयन करें) ।

डीबगिंग करते समय, उस पृष्ठ पर क्लिक करें जहां आपने लंबे समय से देखा है। फिर आउटपुट लॉग देखें - यदि आप एकाधिक आईडी देखते हैं तो आप इससे पीड़ित हो सकते हैं।

यही कारण है कि आप कभी-कभी देरी देख सकते हैं लेकिन अन्य बार नहीं, एप्लिकेशन कोड थोड़ा अलग तरीके से सत्र का उपयोग कर सकता है या सत्र या आईओ ऑपरेशंस पृष्ठ से पृष्ठ पर उच्च या निम्न हो सकता है।

यदि ऐसा कुछ है तो आप साइट पर या प्रत्येक दिए गए पृष्ठ पर सत्र का उपयोग करने के तरीके के आधार पर चीजों को गति देने में मदद करने के लिए कुछ चीजें कर सकते हैं।

पृष्ठों है कि सत्र को संशोधित नहीं के लिए:

<% @Page EnableSessionState="ReadOnly" %> 

पृष्ठों है कि सत्र राज्य का उपयोग नहीं करते के लिए: स्क्रीन के उपयोग नहीं करता है

<% @Page EnableSessionState="False" %> 

(web.config):

<configuration> 
    <system.web> 
     <sessionState mode="Off" /> 
    </system.web> 
</configuration> 

तो चलिए निम्नलिखित उदाहरण लें:

उपयोगकर्ता एक पृष्ठ लोड करता है, फिर पहले अनुरोध को लोड करने से पहले किसी अन्य पृष्ठ पर जाने का निर्णय लेता है ASP.NET एक सत्र लॉक को मजबूर करेगा क्योंकि नया पृष्ठ अनुरोध लोड तब तक प्रतीक्षा करेगा जब तक कि पहला पृष्ठ अनुरोध समाप्त न हो जाए। एएसपी.नेट एमवीसी के साथ प्रत्येक एक्शन सिंक्रनाइज़ेशन के लिए उपयोगकर्ता सत्र को लॉक करता है; एक ही मुद्दा पैदा कर रहा है।

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

संयोग UpdatePanel नियंत्रण समान व्यवहार का कारण बनता है -

http://msdn.microsoft.com/en-us/magazine/cc163413.aspx

क्या किया जा सकता:

यह लॉकिंग समस्या कारणों माइक्रोसॉफ्ट SessionStateUtility वर्ग में से एक है -

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

ताकि आप डिफ़ॉल्ट व्यवहार को ओवरराइड कर सकें अगर आपको इस समस्या का सामना करना पड़ता है जैसा कि इस रेडिस कार्यान्वयन में देखा गया है: https://github.com/angieslist/AL-Redis

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

Answer 2

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

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)] 
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")] 
public class ParallelController : Controller 
{ 
    ... 
} 

मैं भी System.Web.Mvc.MvcHandler.BeginProcessRequest() में देरी, जब कोशिश में कुछ लंबी चलने वाली कार्रवाई करना था और मैं NewRelic में इसे देखा। इस विशेषताओं ने समस्या हल कर दी है और इस नियंत्रक के लिए समानांतर क्रियाओं को संभालने की क्षमता दी है।

Answer 3

इस अनुभव वाले आईआईएस उच्च CPU उपयोग को पढ़ने वाले किसी भी व्यक्ति को जो अनजान है, मैंने इस धागे को न्यूरेलिक समर्थन मंच से खोला है।

मैं इस मुद्दे से एक सप्ताह से अधिक समय से निपट रहा हूं, जब तक मुझे एहसास हुआ कि यह उनका एजेंट था जो समस्या का मूल कारण था।

.NET agent causing high CPU usage on IIS

तो पहली बात मैं सुझाव है कि आप को हटा रहा है की कोशिश करो।नेट एजेंट और देखें कि क्या आप कोई जटिल बदलाव करते हैं, इससे पहले कि आप अधिक जटिल प्रयोगों में कूद जाएं।

मैं इस सवाल को इस विशेष प्रश्न पर पोस्ट करता हूं क्योंकि इस मुद्दे पर काम करते समय मैं यहां पहली बार आया था, और थ्रेड चपलता ने मुझे एक लंबे पाठ्यक्रम पर सेट किया जो सही नहीं था ... (हालांकि स्वयं ही बहुत दिलचस्प है)।

Answer 4

मुझे ऐसे ऐप में एक ही समस्या का सामना करना पड़ा जिसमें सत्रों का बहुत कम उपयोग था। खाते में स्वीकार किए जाते हैं जवाब लेने, और यहां तक ​​कि अस्थायी रूप से नैदानिक ​​प्रयोजनों के लिए पूरी तरह से SessionState हटाने के बाद, मैं अभी भी में प्रदर्शन के साथ महत्वपूर्ण मुद्दों था इस 'विधि'

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

1. मैं अपने डि कंटेनर, जो अपनी वस्तु संकल्प में प्रदर्शन नुकसान हुआ के रूप में Ninject उपयोग कर रहा था:

   मेरे स्थानीय रूपरेखा कुछ चीजें पता चला। मैंने इसे सरल इंजेक्टर के साथ बदल दिया और परिमाण के क्रम से प्रदर्शन में वृद्धि की।

2. मैंने पाया कि कहीं ऑटोमैपर के IQueryable एक्सटेंशन Project().To<>() और लिंक के एसक्यूएल सर्वर प्रदाता के बीच, कि अनुमानित गतिशील संकलन और अनुमानों का JITING मेरे अनुरोध समय के 50% के लिए ज़िम्मेदार था। COMPiledQuerys के साथ इसे बदलने से एक और महत्वपूर्ण दांत बन गया।

आशा है कि यह किसी और की मदद करेगी!