ग्राहक सहायता में PerfView का उपयोग करना

हमारी सहायता टीम में एक उपयोगकर्ता से अनुरोध को संसाधित करने के चरणों में से एक समस्या को पुन: उत्पन्न करना है। प्लेबैक के साथ कठिनाइयाँ विभिन्न कारणों से उत्पन्न होती हैं: उपयोगकर्ता हमेशा एक ऐसे एप्लिकेशन का उदाहरण नहीं दे सकता है जो गलत कोड व्यवहार दिखाता है, या समस्या किसी विशेष वातावरण के लिए विशिष्ट हो सकती है। आज, बड़ी संख्या में सॉफ़्टवेयर, हार्डवेयर कॉन्फ़िगरेशन और वर्चुअल वातावरण का उपयोग किया जाता है, जिसमें हमारे घटकों के साथ लिखे गए प्रोग्राम काम करते हैं। पिक्सल में स्क्रीन की चौड़ाई पांच गुना (800 से 4k तक) हो सकती है। और कॉन्फ़िगरेशन अन्य मापदंडों में भिन्न हो सकते हैं: मेमोरी आकार, डिस्प्ले की संख्या, डीपीआई, सुरक्षा सेटिंग्स, वीडियो कार्ड और इसके ड्राइवर। यह विविधता ग्राहकों से एक विशेष कॉन्फ़िगरेशन के लिए एक स्थिर प्रवाह प्रदान करती है। उदाहरण के लिए, किसी समस्या को केवल Windows के किसी विशिष्ट संस्करण पर, या केवल कुछ DPI सेटिंग्स पर पुन: प्रस्तुत किया जाता है, या यदि उपयोगकर्ता के पास तीन मॉनिटर हैं। इस समस्या को हल करने के लिए, हमारी सहायता टीम कई वर्षों से Microsoft PerfView उपयोगिता का उपयोग कर रही है। यदि समस्या को पुन: उत्पन्न करने के अन्य सभी तरीके समाप्त हो जाते हैं, तो हम उपयोगकर्ता को एक सरल निर्देश देते हैं कि ट्रेसिंग कैसे शुरू करें और हमें परिणामी फ़ाइल भेजें। ट्रेस जानकारी आपको यह समझने में मदद करती है कि वास्तव में समस्या क्या है।

यह लेख तकनीकी सहायता और इस उपयोगिता की सीमाओं में PerfView का उपयोग करने की संभावनाओं पर चर्चा करेगा।

PerfView मूल रूप से आंतरिक उपयोग के लिए बनाया गया था और Microsoft द्वारा विंडोज, .NET CLR और विज़ुअल स्टूडियो के प्रदर्शन को अनुकूलित करने के लिए उपयोग किया गया था। उपयोगिता विंडोज कर्नेल टूल का उपयोग करती है - ETW (विंडोज़ के लिए ईवेंट ट्रेसिंग)

ट्रेस परिणामों की सही व्याख्या करने के लिए, यह समझना महत्वपूर्ण है कि यह उपयोगिता कैसे काम करती है। किसी भी कार्यक्रम को निर्देशित ग्राफ के रूप में दर्शाया जा सकता है, जिसके कोने विधियां होंगी। फिर किसी भी समय प्रोग्राम का कॉल स्टैक मुख्य () विधि से उस विधि का पथ होगा जो वर्तमान में निष्पादित हो रहा है।



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



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

उन विशिष्ट स्थितियों पर विचार करें जहां PerfView तकनीकी सहायता के लिए उपयोगी हो सकता है:
1. आवेदन उपयोगकर्ता पर जमा देता है। यह सबसे सरल चीज है जो हो सकती है। एक हैंग के लिए कॉल कॉल स्टैक ट्रेस में निहित होने की गारंटी है।
2. आवेदन एक त्रुटि के साथ काम करना बंद कर देता है। उसी समय, विंडोज समस्या प्रक्रिया को निलंबित कर देता है और इसके लिए dwwin.exe डीबगिंग प्रक्रिया को कॉल करता है। यह कॉल शॉट्स के बीच के समय की तुलना में अधिक समय लेता है, इसलिए यह कहना सुरक्षित है कि गिरने वाले स्टैक की गिनती भी ट्रेस में मिल जाएगी।
3. आवेदन अपेक्षा के अनुरूप काम नहीं करता है। उदाहरण के लिए, कुछ कॉन्फ़िगरेशन पर, विंडो के आकार बदलने पर एप्लिकेशन अप्रिय रूप से झिलमिलाहट कर सकता है। इस स्थिति में, "अच्छे" और "खराब" कॉन्फ़िगरेशन के साथ निशान के परिणामों की तुलना करना आवश्यक है।
4. उपयोगकर्ता की मशीन पर खराब अनुप्रयोग प्रदर्शन। PerfView मूल रूप से विशेष रूप से एक प्रदर्शन प्रोफाइलर के रूप में बनाया गया था। इस मामले में, उपयोगिता का उपयोग इसके इच्छित उद्देश्य के लिए किया जाता है।

बेशक, PerfView उन स्थितियों में उपयोगी नहीं होगी जहां समस्याग्रस्त कोड एक समय के लिए प्रकट होता है जो शॉट्स के बीच के अंतराल से छोटा होता है और दोहराता नहीं है।

उदाहरण

यह एक सरल WPF एप्लिकेशन के संचालन का विश्लेषण करने का प्रस्ताव है जो स्क्रीन पर रेखाएं खींचता है जब एक उंगली को इसके पार ले जाया जाता है, माउस ड्राइंग भी समर्थित है। तैयार आवेदन यहां से लिया गया था ।
इस तरह से विश्लेषण किया गया आवेदन दिखता है:



कार्य: निम्न परिदृश्यों के लिए विलंब समय का अध्ययन करने के लिए स्क्रीन पर लाइन के प्रदर्शन के लिए इनपुट से देरी समय का अनुमान लगाने के लिए
1. आवेदन एसर Iconia W3 810 टैबलेट के साथ शुरू होता है। टच इनपुट का उपयोग किया जाता है।
2. एसर आईकोनिया डब्ल्यू 3 810 पर एप्लिकेशन का रिमोट लॉन्च और स्पर्श के बजाय माउस इनपुट का उपयोग करें।
एसर का सस्ता और कमजोर टैबलेट कोई संयोग नहीं है। यह काफी धीमा है और इसमें कुछ अन्य, अधिक संसाधन-मांग वाले सॉफ़्टवेयर डेवलपर को चलाने के लिए बहुत कम मेमोरी है।

हम विश्लेषण के लिए डेटा एकत्र करके शुरू करते हैं। PerfView की मुख्य विंडो में, Alt + C दबाएं। एक संवाद दिखाई देगा।



विकल्पों को छोड़ दें जैसे वे हैं, संग्रह को क्लिक करें। अतिरिक्त का विश्लेषण नहीं करने के लिए, डेटा संग्रह के दौरान कार्यों की संख्या को कम करना उचित है। उदाहरण के लिए, आप विश्लेषण किए गए कार्यक्रम को पहले से चला सकते हैं यदि आप रुचि नहीं रखते हैं कि यह कब शुरू होता है। कुछ लाइनें खींचें और स्टॉप कलेक्शन पर क्लिक करें। टैबलेट की छोटी स्क्रीन पर, विश्लेषण करना सुविधाजनक नहीं है, इसलिए हम परिणामस्वरूप * .etl फ़ाइल को एक बड़े कंप्यूटर में स्थानांतरित करते हैं। ट्रेस का विश्लेषण करने के लिए, pdb फ़ाइलों को असेंबली के लिए आवश्यक है जो ट्रेस के समय मशीन द्वारा उठाए गए थे। PerfView अगर आप संग्रह-> मर्ज को अंजाम देते हैं, तो उन्हें etl फ़ाइल के साथ संग्रह में रखता है। उपयोगिता का नवीनतम संस्करण डिफ़ॉल्ट रूप से ऐसा करता है, पुराने संस्करणों में इसे याद रखना आवश्यक था। परिणामी फ़ाइल खोलें।



यहां पर बात करने के लिए बहुत कुछ है, लेकिन अब हम सीपीयू स्टैक्स का चयन करते हैं और ट्रेस पर काम करने वाली सभी प्रक्रियाओं को देखते हैं।



आप उनमें से किसी को भी देख सकते हैं। यह इंटर-प्रोसेस इंटरैक्शन का विश्लेषण करने के लिए PerfView को एक उपयोगी उपकरण बनाता है। ऊपर से तीसरी प्रक्रिया हमारी है। हम इसे चुनते हैं, हम प्राप्त करते हैं।



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



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



इस स्क्रीनशॉट में, आप देख सकते हैं कि PresentationCore.ni! PenThreadWorker.ThreadProc टच इनपुट इवेंट को संसाधित करके ड्राइंग प्रक्रिया शुरू होती है। ट्रेस की शुरुआत से 3,735 मिलीसेकंड के बाद ऐसा हुआ। स्पर्श इनपुट कार्यक्रम को कार्यक्रम में संसाधित किया जाएगा और एक रीड्रा का कारण बनना चाहिए। चूंकि विधियां कॉल समय के अनुसार आदेशित होती हैं, बस तालिका को नीचे फ्लिप करें और रिवरिंग से संबंधित कॉल की तलाश करें।



Wpfgfx में कॉल लगभग तीन मिली सेकेंड के बाद होते हैं, लेकिन यह वह नहीं है जिसकी हमें तलाश थी, क्योंकि इस समय के अंतराल में हमारे एप्लिकेशन का कोड काम नहीं करता था। ऐसा लगता है कि हमने गलती से एक छोटी सी खोज की है - WPF में स्पर्श इनपुट का अपना दृश्य है। यहां तक ​​कि अगर एप्लिकेशन स्पर्श इनपुट घटनाओं को नहीं संभालता है, तो ऐसी घटनाओं के आने पर इसकी खिड़की को फिर से तैयार किया जाएगा। Redrawing के अंत को d3d9 कॉल माना जाएगा! CSwapChain :: Present। पहला रेडव्रा (हमारा नहीं) 3,740 मिली सेकेंड पर हुआ। हम समय अक्ष के साथ आगे बढ़ते हैं। टच इनपुट ईवेंट को एक और 4 मिलीसेकंड के बाद उपयोगकर्ता कोड द्वारा संसाधित किया गया था। नीचे स्टैक हैंडलिंग इवेंट की पूरी गणना है।



D3d9 के लिए अगली कॉल! CSwapChain :: वर्तमान विधि 3,767 मिलीसेकंड पर हुई।
इस प्रकार, लगभग 32 मिलीसेकंड टच इनपुट ईवेंट से उपयोगकर्ता कोड के कारण रीड्रा में पारित हुआ। प्रति सेकंड एक इंच की गति से, दृश्य में देरी लगभग तीन पिक्सेल है।
टैबलेट के दूरस्थ कनेक्शन के मामले में, देरी समय से मिलकर बनेगा: उपयोगकर्ता इनपुट को रिमोट मशीन तक पहुंचाने में देरी, रिमोट मशीन पर फ्रेम बनाने में देरी, दूरस्थ डेस्कटॉप में फ़्रेम प्राप्त करने और प्रदान करने में देरी। इन देरी का मूल्यांकन करने के लिए, उस मशीन पर ट्रेस करना पर्याप्त है जिसके साथ रिमोट डेस्कटॉप लॉन्च किया गया है। यहां केवल विश्लेषण और दिलचस्प निष्कर्षों के परिणाम हैं। हम mstsc.exe प्रक्रिया का विश्लेषण करेंगे। इनपुट संदेश को संसाधित करने में लगने वाले समय की उपेक्षा करते हुए, देरी का समय कॉल से mstscax पर गिना जाएगा! CTSProtocolHandlerBase :: SendBuffer to mstscax पर कॉल करें! COP :: PresentCententGDI उपयोगकर्ता इनपुट को दूरस्थ मशीन पर 14,348 मिलीसेकंड पर स्थानांतरित किया गया था।



उसके बाद, रिमोट मशीन से ग्राफिक डेटा प्राप्त करना और रिमोट डेस्कटॉप एप्लिकेशन विंडो को फिर से तैयार करना 15,139 मिलीसेकंड पर हुआ।



देरी 791 मिली सेकंड की थी। प्रति सेकंड एक इंच की उंगली की गति पर, प्रतिपादन में देरी लगभग 75 पिक्सेल है।

हमें उम्मीद है कि इस लेख को पढ़ने के बाद कम मायावी कीड़े होंगे, और सभी प्रकार के "चमत्कार" और कार्यक्रमों के काम से जुड़े अस्पष्ट क्षण।