एसक्यूएल सर्वर - प्रबंधन स्टूडियो - क्लाइंट सांख्यिकी - सर्वर उत्तर बनाम क्लाइंट प्रोसेसिंग समय

Question

पर प्रतीक्षा करें मेरे पास धीमी गति से चल रही क्वेरी है कि मैं अनुकूलित करने पर काम कर रहा हूं।

प्रबंधन स्टूडियो में क्लाइंट सांख्यिकी को देखते समय इसे सर्वर उत्तरों पर लगभग 8 सेकंड प्रतीक्षा समय और क्लाइंट प्रोसेसिंग समय पर लगभग 1 सेकंड लग रहा था।

मैंने हमेशा सोचा है कि सर्वर उत्तरों पर प्रतीक्षा समय काम करने की संख्या थी और क्लाइंट प्रोसेसिंग समय आमतौर पर बैंडविड्थ या बड़े डेटा आकार से संबंधित था।

मैंने क्वेरी में कई बदलाव किए हैं और अब सर्वर उत्तरों पर मेरा प्रतीक्षा समय लगभग 250ms है, हालांकि, क्लाइंट प्रोसेसिंग का समय लगभग 9 सेकंड तक बढ़ गया है जिससे कुल निष्पादन समय थोड़ा धीमा हो जाता है।

परिणाम सेट लौटाया जाना बिल्कुल वही है।

क्या कोई इस बात पर कोई प्रकाश डाल सकता है कि इन दो संख्याओं के बीच वास्तव में क्या अंतर है और इसका परिणाम क्या होगा?

Answer 1

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

यदि आप सर्वर के उत्तरों पर बड़े 'प्रतीक्षा समय' के साथ कोई क्वेरी चलाते हैं तो इसका मतलब है कि सर्वर ने पहली पंक्ति बनाने के लिए काफी समय लगाया। यह उन प्रश्नों पर सामान्य है जिनके पास ऑपरेटरों को पूरा उप-क्वेरी की आवश्यकता होती है ताकि वे आगे बढ़ने से पहले मूल्यांकन कर सकें (सामान्य उदाहरण सॉर्ट ऑपरेटर है)।

दूसरी तरफ एक बहुत छोटा 'सर्वर उत्तर पर प्रतीक्षा समय' के साथ एक क्वेरी का अर्थ है कि क्वेरी पहली पंक्ति को तेज़ी से वापस करने में सक्षम थी। हालांकि एक लंबे समय तक 'क्लाइंट प्रोसेसिंग टाइम' का तात्पर्य यह नहीं है कि क्लाइंट ने बहुत समय प्रसंस्करण बिताया और सर्वर को क्लाइंट पर इंतजार कर दिया गया था। इसका मतलब यह हो सकता है कि सर्वर परिणाम से पंक्तियों को वापस करना जारी रखता है और यह तब तक चलता है जब तक कि आखिरी पंक्ति वापस नहीं आती।

जो आप देखते हैं वह क्वेरी प्लान में बदलावों का परिणाम है जो संभवतः एक ऑपरेटर को हटा देता है जो निष्पादन को अवरुद्ध कर रहा था (संभवत: एक प्रकार) और नई योजना एक अलग रणनीति का उपयोग करती है जो पहले परिणाम को तेजी से उत्पन्न करती है (संभवत: एक अनुक्रमणिका का उपयोग करती है जो अनुरोधित आदेश की गारंटी देता है, इसलिए मुझे किसी भी तरह की आवश्यकता नहीं है), लेकिन कुल मिलाकर अंतिम समय तक।

आप क्लाइंट सर्वर रोके हुए के बारे में चिंतित हैं, तो सत्र की जांच की जा क्वेरी क्रियान्वित करने के लिए (यह बड़े परिणाम सेट पर हो सकता है) तो आप sys.dm_exec_requests में wait_type की जाँच करनी चाहिए (यह भी sys.dm_os_tasks और sys.dm_os_workers से जानकारी उपयोगी है) । अगर मुझे क्लाइंट प्रतीक्षा प्रकार पर प्रतीक्षा करने वाले सर्वर को गलत नहीं किया गया है तो ASYNC_NETWORK_IO है।आप कुल sys.dm_os_wait_stats को भी देख सकते हैं, इसे DBCC SQLPERF("sys.dm_os_wait_stats" , CLEAR) का उपयोग करके रीसेट करें, फिर क्वेरी चलाएं, देखें कि ASYNC_NETWORK_IO प्रतीक्षा प्रकार कितना समय तक बढ़ता है। बेशक, सुनिश्चित करें कि परीक्षण के दौरान सर्वर पर कोई अन्य गतिविधि नहीं होती है।

Answer 2

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

SQL Server Wait Events: Taking the Guesswork out of Performance Profiling

Analysing Query Performance in SQL Server 2005

Display SQL Server database waits

INF: Client Effects on SQL Server Throughput

Answer 3

ये आंकड़े का वर्णन यहां: http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspx