किन गफाडी SQL एप VPN मा सुस्त हुन्छ र के ब्याच गर्ने

स्थानीय नेटवर्कमा एक सेकेन्डभन्दा कम समयमा खुल्ने फारम VPN मा पाँच सेकेन्ड लिन्छ, जबकि त्यही लिङ्कमा फाइल प्रतिलिपि पूर्ण गतिमा चल्छ। फरक ब्यान्डविथमा छैन। फारमले उत्तरहरूको शृंखला कुर्छ र प्रत्येक चरणमा पूरै राउन्ड ट्रिप तिर्छ, जबकि फाइल प्रतिलिपिले बाइटहरू निरन्तर उडानमा राख्छ। पहुँच लाइन छुनुअघि ती प्रतीक्षाहरू गन्नुहोस्।

लक्षण स्क्रिन हो, क्वेरी होइन

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

त्यसैले गति परीक्षण निर्दोष देखिन्छ। ठूलो स्थानान्तरणले थ्रूपुट मापन गर्छ, गफाडी फारमले ढिलाइ मापन गर्छ, र VPN एउटामा उत्कृष्ट हुँदै अर्कोमा सामान्य रहन सक्छ। त्यसैले स्क्रिनको निदान भन्नाले लिङ्क होइन, स्क्रिन मापन गर्नु हो।

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

एक प्रयोगकर्ता कार्यमा क्रमिक प्रतीक्षाहरू गन्नुहोस्

अनुमान गर्नुको सट्टा ग्राहकमा मापन राख्नुहोस्। psql मा \timing on ले प्रत्येक विवरणको बितेको समय छाप्छ, र EXPLAIN (ANALYZE, BUFFERS) ले त्यो समयमध्ये सर्भरले वास्तवमा काममा कति खर्च गर्यो देखाउँछ।

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

नतिजा क्रमिक प्रतीक्षाहरूको गणनाका रूपमा लेख्नुहोस्। अर्का दुई खण्डले घटाउन सक्ने मात्रा त्यही हो, र यो प्रमाणसहित बहस गर्न सकिने संख्या हो।

स्वतन्त्र कलहरू ब्याच गर्नुहोस्, आश्रित राख्नुहोस्

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

समुच्चयमा आधारित कामले ब्याचिङभन्दा बढी गहिराइसँग प्रतीक्षाहरू हटाउँछ। लुपले एक-एक गरी लिइरहेका पङ्क्तिहरू फर्काउने एउटा क्वेरीले लुप र राउन्ड ट्रिप दुवै हटाउँछ। पहिले लुप खोज्नुहोस्, किनभने यो सामान्यतया ठूलो लाभ र समीक्षा गर्न सजिलो परिवर्तन हो।

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

ब्यान्डविथ किन्नुअघि जडानहरू पुनः प्रयोग गर्नुहोस्

नयाँ जडानले नाम समाधान, TCP ह्यान्डशेक, TLS वार्ता र प्रमाणीकरण खर्च गर्छ, र उच्च ढिलाइ भएको बाटोमा ती प्रत्येक पहिलो क्वेरी चल्नुअघिको अर्को राउन्ड ट्रिप हो। जडान पूलहरू त्यो खर्च प्रत्येक कलमा होइन, प्रत्येक प्रक्रियामा एक पटक तिर्नका लागि छन्।

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

पूलिङले सेटअप खर्च हटाउँछ र क्रमिक क्वेरी प्रतीक्षाहरूलाई अछूतो राख्छ। यो आफैंमा सुधार होइन, सफा मापनको पूर्वशर्त हो।

कार्यान्वयनलाई डेटाको नजिक सार्ने विचार गर्नुहोस्

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

कुनै पनि दिशा छिटो छ भनी अनुमान गर्नुअघि वास्तविक इन्टरफेस र यसले सार्ने डेटा मापन गर्नुहोस्। टाढाको डेस्कटप सत्रले पिक्सेल सार्छ, र बाक्लो ग्राफिक्स भएको स्क्रिनले त्यही बाटोमा यसले प्रतिस्थापन गरेका क्वेरीहरूभन्दा नराम्रो प्रदर्शन गर्न सक्छ, विशेषगरी जब ग्राहकले निरन्तर पुनः कोर्छ।

त्यसपछि मूल कार्य दोहोर्याउनुहोस् र तीन संख्या तुलना गर्नुहोस्: क्रमिक प्रतीक्षा, नतिजाको मात्रा र सुरुदेखि अन्त्यसम्मको पूर्णता समय। डेटाको शुद्धता र पहुँच नीति जोगाउँदै मापन गरिएको प्रयोगकर्ता कार्य सुधार्ने परिवर्तन नै राख्न योग्य हो।