एक बातूनी SQL ऐप VPN पर क्यों धीमा चलता है और क्या बैच करना चाहिए

लैन पर एक सेकंड से कम में दिखने वाला फ़ॉर्म VPN पर पाँच सेकंड लेता है, जबकि उसी लिंक पर फ़ाइल कॉपी पूरी गति से चलती है। अंतर बैंडविड्थ का नहीं है। फ़ॉर्म जवाबों के क्रम का इंतज़ार करता है और हर कदम पर पूरी राउंड ट्रिप चुकाता है, जबकि फ़ाइल कॉपी बाइट्स को लगातार रास्ते में रखती है। एक्सेस लाइन छूने से पहले उन इंतज़ारों को गिनें।

लक्षण स्क्रीन है, क्वेरी नहीं

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

इसीलिए स्पीड टेस्ट निर्दोष दिखता है। बल्क ट्रांसफ़र थ्रूपुट मापता है, बातूनी फ़ॉर्म विलंब मापता है, और VPN एक में बेहतरीन और दूसरे में साधारण हो सकता है। इसलिए स्क्रीन का निदान करने का अर्थ लिंक नहीं, स्क्रीन मापना है।

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

एक उपयोगकर्ता क्रिया में क्रमिक इंतज़ार गिनें

अनुमान लगाने के बजाय क्लाइंट में मापें। psql में \timing on हर स्टेटमेंट का बीता समय छापता है, और EXPLAIN (ANALYZE, BUFFERS) दिखाता है कि उस समय में से सर्वर ने वास्तव में कितना काम पर खर्च किया।

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

परिणाम को क्रमिक इंतज़ारों की गिनती के रूप में लिखें। अगले दो खंड जिस मात्रा को घटा सकते हैं वही यह है, और यह ऐसी संख्या है जिस पर आप सबूत के साथ बहस कर सकते हैं।

स्वतंत्र कॉल बैच करें, निर्भर रखें

जो दो स्टेटमेंट एक-दूसरे के परिणाम नहीं पढ़ते, वे साथ चल सकते हैं और एक बार इकट्ठे हो सकते हैं, जिससे दो इंतज़ार एक बन जाते हैं। जिन दो स्टेटमेंट में दूसरे को पहले का मान चाहिए, वे ऐसा नहीं कर सकते, क्योंकि निर्भरता वास्तविक है और बैच करने से प्रोग्राम का व्यवहार बदल जाएगा। कुछ भी फिर से लिखने से पहले कॉल को इन दो ढेरों में बाँटें, और हर ढेर का आकार बताता है कि क्या संभव है।

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

बैच को अब भी त्रुटि प्रबंधन और लेनदेन सीमाएँ बनाए रखनी होंगी। असंबंधित स्टेटमेंट को एक स्ट्रिंग में जोड़ना सुरक्षित अनुकूलन नहीं है, और जो बैच विफल स्टेटमेंट को सफल सबमिशन के पीछे छिपाता है, वह बचाए गए इंतज़ारों से भी बुरा है।

बैंडविड्थ खरीदने से पहले कनेक्शन दोबारा उपयोग करें

नया कनेक्शन नाम विश्लेषण, TCP हैंडशेक, TLS बातचीत और प्रमाणीकरण का खर्च करता है, और उच्च विलंब वाले रास्ते पर इनमें से हर एक पहली क्वेरी चलने से पहले एक और राउंड ट्रिप है। कनेक्शन पूल इसलिए हैं कि यह लागत प्रति कॉल नहीं, प्रति प्रक्रिया एक बार चुकाई जाए।

ADO.NET में पूल किया गया कनेक्शन बंद या नष्ट करने पर नया भौतिक कनेक्शन खोलने के बजाय वह पुनः उपयोग के लिए लौट आता है, इसलिए लीक जैसा दिखने वाला पैटर्न अक्सर सही उपयोग होता है। मान लेने के बजाय जाँचें कि पूल वास्तव में उपयोग हो रहा है: भौतिक कनेक्शन बनने का लॉग रखें, या स्क्रीन चलने के दौरान सर्वर पर सत्रों की संख्या देखें। SQL प्रदर्शन मार्गदर्शन भी राउंड ट्रिप घटाने और बार-बार होने वाले एड हॉक कॉल बैच करने की वही बात कहता है, सेवा-विशिष्ट उदाहरणों के साथ जिन्हें आपको अपनी तैनाती पर लागू करना चाहिए।

पूलिंग सेटअप लागत हटाती है और क्रमिक क्वेरी इंतज़ारों को अछूता छोड़ती है। यह अपने आप में सुधार नहीं, साफ़ माप की पूर्वशर्त है।

निष्पादन को डेटा के करीब ले जाने पर विचार करें

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

किसी भी दिशा को तेज़ मानने से पहले वास्तविक इंटरफ़ेस और उसके द्वारा भेजे जाने वाले डेटा को मापें। दूरस्थ डेस्कटॉप सत्र पिक्सेल ले जाता है, और घने ग्राफ़िक्स वाली स्क्रीन उसी रास्ते पर उन क्वेरी से बुरी चल सकती है जिन्हें उसने बदला, ख़ासकर जब क्लाइंट लगातार फिर से चित्र बनाता है।

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