गप्पिष्ट SQL ॲप VPN वर का सावकाश चालते आणि काय बॅच करावे

स्थानिक नेटवर्कवर एका सेकंदापेक्षा कमी वेळात उघडणारा फॉर्म VPN वर पाच सेकंद घेतो, तर त्याच लिंकवरील फाइल प्रत पूर्ण वेगाने धावते. फरक बँडविड्थमध्ये नाही. फॉर्म उत्तरांच्या क्रमाची वाट पाहतो आणि प्रत्येक टप्प्यावर पूर्ण फेरी मोजतो, तर फाइल प्रत बाइट्स सतत उडण्यात ठेवते. प्रवेश लाइनला हात लावण्यापूर्वी त्या प्रतिक्षा मोजा.

लक्षण स्क्रीन आहे, क्वेरी नाही

त्या स्क्रीनवरील प्रत्येक क्वेरी वेगवान असू शकते आणि स्क्रीन तरीही संथ असू शकतो, कारण एकूण बेरीज अंमलबजावणीच्या वेळांची नाही, प्रतिक्षांची आहे. दोन मिलिसेकंदात धावणारे विधान तरीही पूर्ण फेरी मोजते, कारण पुढील पाठवण्यापूर्वी क्लायंटला त्याचा निकाल मिळणे आवश्यक असते. चाळीस मिलिसेकंद विलंबाच्या मार्गावर शंभर अवलंबित कॉल कोणतेही रेंडरिंग काम सुरू होण्यापूर्वी सुमारे चार सेकंदांत साचतात. हे अंकगणित प्रतिक्षेचे प्रतिरूप आहे, तुमच्या लिंकचे मापन नाही.

म्हणूनच वेग चाचणी निर्दोष दिसते. मोठ्या प्रमाणातील हस्तांतरण थ्रूपुट मोजते, गप्पिष्ट फॉर्म विलंब मोजतो, आणि VPN एका गोष्टीत उत्कृष्ट राहून दुसऱ्यात सामान्य राहू शकते. म्हणून स्क्रीनचे निदान म्हणजे लिंकऐवजी स्क्रीन मोजणे.

काहीही बदलण्यापूर्वी एका वापरकर्ता क्रियेची सुरुवात ते शेवटची वेळ नोंदवा. नंतरची दुरुस्ती फळली का हे सांगू शकणारा एकमेव आधार तो आकडा आहे.

एका वापरकर्ता क्रियेतील क्रमिक प्रतिक्षा मोजा

अंदाज लावण्याऐवजी क्लायंटमध्ये मोजमाप बसवा. psql मध्ये \timing on प्रत्येक विधानाची गेलेली वेळ छापते, आणि EXPLAIN (ANALYZE, BUFFERS) त्या वेळेपैकी किती सर्व्हरने खरेच कामावर घालवली हे दाखवते.

त्या दोन आकड्यांमधील फरक हा तुमचा नेटवर्क आणि क्लायंट खर्च आहे. एखादे विधान दोन मिलिसेकंदात धावले आणि क्लायंटने साठ नोंदवले, तर उर्वरित अठ्ठावन्न प्रवास आणि स्थानिक प्रक्रिया आहेत, आणि कोणताही निर्देशांक त्या काढणार नाही. स्क्रीन पाठवणाऱ्या प्रत्येक विधानासाठी ही तुलना पुन्हा करा आणि अंमलबजावणीच्या वेळा नाही तर फरक बेरीज करा.

निकाल क्रमिक प्रतिक्षांच्या संख्येत नोंदवा. पुढील दोन विभाग हेच प्रमाण कमी करू शकतात, आणि हा पुराव्यासह वाद घालता येणारा आकडा आहे.

स्वतंत्र कॉल बॅच करा, अवलंबित ठेवा

एकमेकांचा निकाल न वाचणारी दोन विधाने एकत्र प्रवास करून एकदाच गोळा होऊ शकतात, ज्यामुळे दोन प्रतिक्षा एक होतात. दुसऱ्याला पहिल्याचे मूल्य आवश्यक असलेली दोन विधाने असे करू शकत नाहीत, कारण अवलंबन खरे आहे आणि बॅच केल्यास कार्यक्रम जे करतो ते बदलेल. काहीही पुन्हा लिहिण्यापूर्वी कॉलची ती दोन रास करा, आणि प्रत्येक रासीचा आकार काय शक्य आहे ते सांगतो.

संचाधारित काम बॅचिंगपेक्षा अधिक सखोलपणे प्रतिक्षा काढून टाकते. लूप एक-एक करून घेत असलेल्या ओळी परत देणारी एक क्वेरी लूप आणि फेऱ्या दोन्ही दूर करते. आधी लूप शोधा, कारण तो सहसा मोठा फायदा आणि पुनरावलोकनास सोपा बदल असतो.

बॅचला तरीही त्रुटी हाताळणी आणि व्यवहाराच्या सीमा जपाव्या लागतात. असंबंधित विधाने एका स्ट्रिंगमध्ये जोडणे हे सुरक्षित इष्टतमीकरण नाही, आणि अपयशी विधान यशस्वी सबमिशनमागे लपवणारी बॅच वाचवलेल्या प्रतिक्षांपेक्षा वाईट आहे.

बँडविड्थ खरेदी करण्यापूर्वी कनेक्शन पुन्हा वापरा

नवीन कनेक्शनला नाव निराकरण, TCP हस्तांदोलन, TLS वाटाघाटी आणि प्रमाणीकरणाचा खर्च येतो, आणि उच्च विलंबाच्या मार्गावर त्यातील प्रत्येक पहिली क्वेरी धावण्यापूर्वीची अजून एक फेरी आहे. कनेक्शन पूल हा खर्च प्रत्येक कॉलला नाही तर प्रत्येक प्रक्रियेला एकदा मोजण्यासाठी अस्तित्वात आहेत.

ADO.NET मध्ये पूलमधील कनेक्शन बंद करणे किंवा dispose करणे नवीन भौतिक कनेक्शन उघडण्याऐवजी ते पुनर्वापरासाठी परत देते, म्हणून गळतीसारखा दिसणारा नमुना बऱ्याचदा योग्य वापर असतो. पूल खरोखर वापरात आहे का हे गृहीत न धरता तपासा: भौतिक कनेक्शन तयार होण्याची नोंद करा, किंवा स्क्रीन धावत असताना सर्व्हरवरील सत्रांची संख्या पाहा. SQL कार्यक्षमता मार्गदर्शन फेऱ्या कमी करणे आणि वारंवार होणाऱ्या ad hoc कॉलचे बॅचिंग याबाबत तोच मुद्दा मांडते, सेवा-विशिष्ट उदाहरणांसह, जी तुम्ही तुमच्या स्वतःच्या उपयोजनावर मॅप करावीत.

पूलिंग सेटअप खर्च काढते आणि क्रमिक क्वेरी प्रतिक्षा अशाच ठेवते. ते स्वतःची दुरुस्ती नसून स्वच्छ मापनाची पूर्वअट आहे.

अंमलबजावणी डेटाच्या जवळ नेण्याचा विचार करा

ॲप डेटाबेसजवळ चालवल्यास अनेक दूरस्थ डेटाबेस देवघेवी एका दूरस्थ प्रदर्शन सत्राने बदलतात. गप्पिष्ट कामभारासाठी हा मोठा बदल असू शकतो, आणि तो कार्यक्षमतेइतकाच कार्यचालनाचा बदल आहे: सत्र व्यवस्थापन, प्रवेश नियंत्रण, सॉफ्टवेअर उपयोजन आणि वापरकर्ता अनुभव हे सर्व ॲपसोबत हलतात.

कोणतीही दिशा वेगवान आहे असे गृहीत धरण्यापूर्वी प्रत्यक्ष इंटरफेस आणि तो हस्तांतरित करणारा डेटा मोजा. दूरस्थ डेस्कटॉप सत्र पिक्सेल हलवते, आणि दाट ग्राफिक्स असलेला स्क्रीन त्याच मार्गावर त्याने बदललेल्या क्वेरींपेक्षा वाईट कामगिरी करू शकतो, विशेषतः क्लायंट सतत पुन्हा रेखाटत असताना.

मग मूळ क्रिया पुन्हा करा आणि तीन आकडे तुलना करा: क्रमिक प्रतिक्षा, निकालाचे प्रमाण आणि सुरुवात ते शेवट पूर्ण होण्याची वेळ. डेटाची अचूकता आणि प्रवेश धोरण टिकवून मोजलेले वापरकर्ता कार्य सुधारणारा बदल हाच ठेवण्यासारखा आहे.