मेरे पास क्लाइंट/सर्वर ऐप है। सर्वर घटक चलाता है, डब्ल्यूसीएफ का उपयोग 'रिमोटिंग' फैशन (बाइनरी फॉर्मेटर, सत्र ऑब्जेक्ट्स) में करता है।सी # कोड डीबगर संलग्न के साथ बहुत धीमी है; MemoryMappedFile की गलती?
यदि मैं सर्वर घटक शुरू करता हूं और क्लाइंट लॉन्च करता हूं, तो पहला कार्य सर्वर < 0.5sec में पूरा करता है।
यदि मैं संलग्न वीएस डीबगर के साथ सर्वर घटक शुरू करता हूं, और उसके बाद क्लाइंट लॉन्च करता हूं, तो कार्य पूरा होने के लिए 20sec से ऊपर ले जाता है।
कोई कोड परिवर्तन नहीं है - कोई सशर्त संकलन परिवर्तन नहीं। वही होता है कि क्या मेरे पास सर्वर घटक संकलित है और 32-बिट, 64-बिट में चल रहा है, वीएस होस्टिंग प्रक्रिया के साथ, वीएस होस्टिंग प्रक्रिया के बिना, या उन चीजों का कोई संयोजन।
संभवत: महत्वपूर्ण: यदि मैं VS.NET प्रोफाइलर (नमूना मोड) का उपयोग करें, तो एप्लिकेशन के रूप में जल्दी के रूप में अगर कोई डिबगर संलग्न थे चलाता है। तो मैं इस तरह से इसका निदान नहीं कर सकता। बस चेक किया गया, उपकरण मोड भी तेजी से चलता है। समवर्ती प्रोफाइलिंग मोड के लिए, जल्दी से काम करता है।
कुंजी डेटा:
- एप्लिकेशन काफी भारी बहु सूत्रण (मानक थ्रेड पूल में 40 धागे) का उपयोग करता है। थ्रेड बनाना तेजी से होता है और धीमा बिंदु नहीं होता है। कई ताले हैं,
WaitHandle
एस औरMonitor
पैटर्न - ऐप में कोई अपवाद नहीं है।
- ऐप कोई कंसोल आउटपुट नहीं बनाता है।
- ऐप पूरी तरह से प्रबंधित कोड है। 1x750MB और 12x8MB और कुछ छोटे
मापा प्रदर्शन:
- CPU उपयोग दोनों ही मामलों में कम से कम है; जब डीबगर संलग्न होता है, तो CPU < पर 1%
- मेमोरी उपयोग दोनों मामलों में न्यूनतम है; शायद दोनों ही मामलों
- हो रहा (सन्दर्भ MMF) पेज दोष के बहुत सारे हैं में 50 या 60MB, लेकिन वे और अधिक धीरे धीरे हो सकता है जब डिबगर
- जुड़ा हुआ है, तो वी.एस. होस्टिंग प्रक्रिया नहीं किया जाता है, या मूल रूप से 'दूरस्थ डीबगिंग मॉनीटर 'खेल में आता है, फिर कि एक सभ्य राशि सीपीयू का उपयोग करता है और पेज दोषों की एक अच्छी संख्या बनाता है। लेकिन यह समस्या नहीं है कि समस्या
- प्रदर्शन अंतर को क्लाइंट चलाने के तरीके के बावजूद देखा जाता है। एकमात्र चर बदल दिया जा रहा है सर्वर सर्वर को एक्सप्लोरर से लॉन्च किए गए 'डीबगिंग के साथ प्रारंभ करें' के माध्यम से चलाया जा रहा है।
मेरे विचार:
- WCF धीमी गति से जब डिबग?
- डीबग किए जाने पर MemoryMappedFiles धीमा?
- 40 धागे का इस्तेमाल किया - डीबग करने में धीमा? शायद मॉनीटर/ताले डीबगर को सूचित करते हैं?थ्रेड शेड्यूलिंग अजीब/संदर्भ स्विच बहुत कम हो जाता है?
- लौकिक पृष्ठभूमि विकिरण वी.एस.
सभी के लिए खुफिया और हास्य की क्रूर भावना देने मूर्खता से संभावना नहीं लग रहे हैं।
तो, मेरे सवालों का:
- क्यों हो रहा है?
- यदि # 1 अज्ञात है, तो मैं निदान/पता कैसे लगा सकता हूं?
के लिए देखें क्या आपने पहली मौका अपवाद पकड़ सक्षम की है? आप डीबग मोड में अधिकतम अंतर्निहित "छिपा" अपवादों को पकड़ने के लिए .NET सर्वर स्रोत स्टेपिंग को सक्षम करने का भी प्रयास कर सकते हैं, विशेष रूप से (डी) serlization वाले। इसके अलावा, निशान के बारे में क्या (outputdebugstring या अन्य)? –
हां, कोई अपवाद नहीं फेंक दिया गया है - अपवाद की सभी श्रेणियां (.NET सहित) पहली मौका के लिए सक्षम हैं। कोई डीबग कंसोल आउटपुट नहीं है (यही मेरा मतलब है कंसोल आउटपुट द्वारा - मैं स्पष्टीकरण के लिए संपादित करूंगा)। मैंने अभी .NET Framework Source Stepping सक्षम किया है (सर्वर स्रोत स्टेपिंग नहीं देख सका) .. कुछ अपवाद पाए गए। डब्ल्यूसीएफ से तत्काल –
अपवाद अपडेट करेगा: "द" चरित्र, हेक्साडेसिमल मान 0x20, को किसी नाम में शामिल नहीं किया जा सकता है। "मुझे * कोई विचार नहीं था * अपवादों को इस तरह से छुपाया जा सकता है: अपवाद अपवाद नहीं है? देखेंगे कि मैं हल करने के लिए क्या कर सकता हूं। शायद आप एक उत्तर पोस्ट कर सकते हैं ताकि अगर आप इसे हल करते हैं तो आप कुछ अपवॉट/स्वीकार कर सकते हैं? :) –