कोड पिंग टाइम मीटर - क्या यह सच में सच है?

सौभाग्य से, आमतौर पर इसका मतलब यह नहीं होता है।

आपके समीकरण में अनुपलब्ध चर यह है कि आपका डेटाबेस और . कैसा है आपका एप्लिकेशन सर्वर और आपके स्टैक हैंडल में और कुछ भी concurrency ।

MySQL के दृष्टिकोण से इसे कड़ाई से स्पष्ट करने के लिए, मैंने एक परीक्षण क्लाइंट प्रोग्राम लिखा, जो MySQL सर्वर से निश्चित संख्या में कनेक्शन स्थापित करता है, प्रत्येक अपने स्वयं के थ्रेड में (और इसलिए, लगभग एक ही समय में सर्वर को एक क्वेरी जारी करने में सक्षम) .

एक बार जब सभी थ्रेड्स ने वापस संकेत कर दिया कि वे जुड़े हुए हैं, तो उन सभी को एक ही समय में उनकी क्वेरी भेजने के लिए एक संदेश भेजा जाता है।

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

कार्यक्रम इस तरह से लिखा गया है कि यह सर्वर से कनेक्शन स्थापित करने के लिए आवश्यक समय की गणना नहीं करता है, क्योंकि एक अच्छे व्यवहार वाले एप्लिकेशन में कनेक्शन पुन:प्रयोज्य होंगे।

क्वेरी थी SELECT SQL_NO_CACHE COUNT(1) FROM ... (एक InnoDB तालिका जिसमें लगभग 500 पंक्तियाँ हैं)।

threads  1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads  2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads  4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads  8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841

टाइम्स सेकंड में हैं। न्यूनतम/अधिकतम/औसत एक ही क्वेरी को चलाने में सबसे अच्छा/सबसे खराब/औसत समय होता है। 64 की संगामिति पर, आप देखते हैं कि सबसे अच्छा मामला केवल 1 क्वेरी के साथ सबसे अच्छे मामले से अलग नहीं था। लेकिन यहां सबसे बड़ा टेक-ऑफ कुल रनटाइम कॉलम है। यह मान उस समय का अंतर है जब पहले थ्रेड ने अपनी क्वेरी भेजी थी (वे सभी अपनी क्वेरी अनिवार्य रूप से एक ही समय पर भेजते हैं, लेकिन "ठीक" उसी समय असंभव है क्योंकि मेरे पास चलाने के लिए 64-कोर मशीन नहीं है परीक्षण स्क्रिप्ट चालू) जब अंतिम थ्रेड को इसकी प्रतिक्रिया मिली।

अवलोकन:अच्छी खबर यह है कि 64 प्रश्नों में औसतन 0.005586 सेकेंड का समय लगता है, निश्चित रूप से 64 * 0.005586 सेकेंड =0.357504 सेकेंड की आवश्यकता नहीं थी ... इसे 64 * 0.001089 (सर्वोत्तम केस टाइम) =0.069696 सभी उन प्रश्नों में से 0.019841 सेकंड के भीतर शुरू और समाप्त हो गए थे... या सैद्धांतिक रूप से उन्हें एक के बाद एक चलाने में लगने वाले समय का केवल लगभग 28.5%।

निश्चित रूप से बुरी खबर यह है कि 64 की संगामिति पर इस क्वेरी पर औसत निष्पादन समय उस समय से 5 गुना अधिक है जब इसे केवल एक बार चलाया जाता है ... और सबसे खराब स्थिति लगभग 14 गुना अधिक होती है। लेकिन यह अभी भी एकल-क्वेरी निष्पादन समय से एक रेखीय एक्सट्रपलेशन से कहीं बेहतर है जो सुझाव देगा।

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

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

आपके बेंचमार्क से एक बड़ा अज्ञात यह है कि डेटाबेस द्वारा प्रश्नों का उत्तर देने में कितना समय व्यतीत होता है, लॉजिक व्यवसाय को निष्पादित करने वाले एप्लिकेशन सर्वर द्वारा कितना समय व्यतीत किया जाता है, और कोड द्वारा कितना समय व्यतीत किया जाता है पृष्ठ परिणामों को HTML में प्रस्तुत करना।