परीक्षण प्रदर्शन के लिए दो दृष्टिकोण। का चयन

यह लेख अनुप्रयोग प्रदर्शन के परीक्षण के लिए सबसे आम दृष्टिकोण का वर्णन करता है; "जीवन से" एनालॉग्स का उपयोग करना और लेखक के अनुभव से उदाहरण, वह दिखाता है कि ऐसा क्यों नहीं किया जा सकता है; और अंत में, डेवलपर्स, प्रबंधकों और अन्य अच्छे लोगों के उज्ज्वल दिमाग में तनाव परीक्षण के महत्व की समझ की एक चिंगारी को फेंकने की कोशिश कर रहा है।



चलिए कुछ कहानियों के साथ शुरू करते हैं।



इतिहास ए।



दूसरे दिन मैं एक प्रोग्रामर के साथ बात कर रहा था। वह सी ++ में लिखते हैं, शिकागो में एक बड़ी कंपनी के लिए काम करता है; सॉफ्टवेयर, जिसके निर्माण में वह शामिल था, वित्तीय और व्यापारिक कंपनियों द्वारा सक्रिय रूप से उपयोग किया जाता है। हम कहते हैं, उत्पाद में कोड की 600 हजार लाइनें हैं। यह सब स्टॉक आंकड़ों के विश्लेषण के लिए एक छोटे से आवेदन के साथ शुरू हुआ, और अब इस तरह के एक राक्षस ने 20 वर्षों तक लहराया है। महान, मैं कहता हूं। सम्मान की प्रेरणा देता है। और आप इसे कैसे परीक्षण करते हैं, आपका राक्षस? इसके लिए, प्रोग्रामर मुझे जवाब देता है, एक विशेष भारतीय है। वह कुछ प्रकार के परीक्षण मामलों को करता है, रिपोर्ट लिखता है। और उससे पहले, एक प्रबंधक ऐसा कर रहा था, लेकिन उसने अधिक से अधिक मैनुअल परीक्षण किया। उदाहरण के लिए नए कार्यों की जाँच की। अब यहाँ एक भारतीय है। खैर, मैं शिकार करना जारी रखता हूं, यह कार्यात्मक परीक्षण है। क्या आप किसी तरह प्रदर्शन का परीक्षण करते हैं? नहीं, वे कहते हैं, अगर ग्राहक धीमे काम की शिकायत करने लगते हैं, तो हम खुद अड़चनें तलाश रहे हैं और उन्हें स्वयं ठीक कर रहे हैं। जो एक उत्पाद विकसित करता है वह बेहतर जानता है। कौन सा परीक्षक इसे संभाल सकता है?



एक स्मार्ट आदमी, मैंने सोचा, और वह बकवास कर रहा है।



इतिहास बी।



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



स्मार्ट आदमी, मैंने फिर से सोचा, लेकिन मैं पूरी तरह से नहीं समझता कि वह क्या कर रहा है।

* * *

ये दो मामले सबसे विशिष्ट लोड परीक्षण दृष्टिकोण का वर्णन करते हैं। उन्हें इस प्रकार संक्षेप में वर्णित किया जा सकता है:

A: “जब प्रदर्शन की समस्याएं होती हैं, तो हम तय करेंगे। खुद को। हमें किसी विशेष परीक्षक की आवश्यकता नहीं है। "

बी: "... और फिर हमने देखा कि सर्वर पर सीपीयू डेटाबेस के साथ सामना नहीं करता है!" MySQL + CPU समस्या "को गुगली किया, एक अद्भुत पुस्तकालय पाया, इसे स्थापित किया, और एन समय से लोड कम हो गया। अब सब कुछ ठीक है।"

* * *

आइए दृष्टिकोण बी की आलोचना के साथ शुरू करें (चलो इसे वर्णमाला का दुरुपयोग करने के लिए "व्यवस्थापक" कहते हैं)। तो, "व्यवस्थापक" दृष्टिकोण की प्रमुख समस्या प्रदर्शन समस्या पर गलत दृष्टिकोण है।



जैसा कि ऊपर की कहानी से देखा जा सकता है, व्यवस्थापक व्यवस्थापक की आंखों से देखता है। उसके लिए समस्या का एक संकेतक सर्वर पर लोड है, संकेतक जिसके द्वारा वह बेहतर के लिए स्थिति में बदलाव का न्याय करता है - अनुरोधों, कनेक्शनों आदि की संख्या और गति। सवाल यह है कि दुनिया के कितने और लोग एक ही साइट पर एक ही तरह से एक ही समस्या को देखते हैं? सही उत्तर शून्य है। साइट पर जाने वाले उपयोगकर्ताओं को डेटाबेस में अनुक्रमित के बारे में चिंता करने की कोई इच्छा नहीं है। वे सीपीयू और डिस्क सबसिस्टम के ग्राफिक्स लोड में रुचि नहीं रखते हैं। अधिकतम जो वे कह सकते हैं: "यह साइट धीमी है।" और एक और बात: "मैं कुछ के लिए एक ही लग रही है, लेकिन तेजी से होगा।" एसक्यूएल प्रश्नों और केवल देखभाल करने वालों की संख्या के आधार पर प्रदर्शन को मापने वालों का अनुपात "ताकि पृष्ठ धीमा न हो" 1 से एन है, जहां एन साइट के सभी आगंतुक हैं, और 1 एक बहुत ही स्मार्ट लेकिन अकेला प्रशासक है।



... जब मैं प्रवेशकर्ताओं से यह सब कहता हूं, तो वे आमतौर पर मुझे कुछ इस तरह जवाब देते हैं "लेकिन उपयोगकर्ता यह नहीं जानते कि यह सब कैसे काम करता है। और हम जानते हैं। और फिर, उपयोगकर्ताओं की राय के आधार पर, समस्या के स्रोत को निर्धारित करना लगभग असंभव है। " इसके लिए मेरे पास एक ऐसा तैयार उत्तर है जो बिना असफलता के काम करता है। जब आप डॉक्टर के पास आते हैं, तो वह आपसे क्या पूछ रहा है? स्वास्थ्य के बारे में। दबाव और तापमान केवल बाद में मापा जाता है, विश्लेषण के लिए दिशा तुरंत नहीं दी जाती है। और वे सवालों से शुरू करते हैं जैसे - "यह कहाँ चोट करता है?", या "जब बदतर होता है - सुबह या शाम को?"। प्रश्न सरल हैं, हमेशा उनके लिए गणितीय रूप से सटीक उत्तर देना संभव नहीं है, लेकिन यह उन पर है कि रोग के लक्षण निर्धारित किए जाते हैं। और, अंततः, यह उन लक्षणों से राहत है जो रोगी को सबसे अधिक प्रसन्न करते हैं। "मुझे कुछ लिखें ताकि यह आहत न हो।" या, हमारे मामले में - "प्रति पृष्ठ कम से कम 200 अनुरोध करें, लेकिन इतना धीमा न करें"। बेशक, एक अच्छा डॉक्टर केवल यह बताकर निदान नहीं करेगा कि रोगी कैसा महसूस करता है। लेकिन उसी तरह, वह उसे कभी भी कम नहीं समझेगा या बुरा, उसे नजरअंदाज करेगा।



कुल - "व्यवस्थापक दृष्टिकोण" खराब है, क्योंकि यह एप्लिकेशन या साइट के वास्तविक उपयोगकर्ताओं के दृष्टिकोण से प्रदर्शन समस्याओं पर विचार नहीं करता है। यह विकल्प संभवतः सर्वरों के लिए उपयुक्त है, लेकिन ग्राहकों के लिए नहीं। हालाँकि, यदि क्लाइंट्स की संख्या लगभग सर्वरों की संख्या के बराबर है ... मुझे आशा है कि यह आपका मामला नहीं है।



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



उदाहरण 1 : ओरेकल के आँकड़ों के विश्लेषण से पता चला कि यदि आप एक इंडेक्स का निर्माण करते हैं तो एक क्वेरी को दो बार तेजी से निष्पादित किया जाएगा। सूचकांक बनाया गया था, क्वेरी 1 सेकंड के बजाय 0.5 से चलना शुरू हुई, ऑपरेशन का प्रतिक्रिया समय 35 से 34.5 सेकंड तक कम हो गया।



उदाहरण 2 : एक निश्चित ऑपरेशन को अनुकूलित किया गया था ताकि उसके निष्पादन के दौरान सर्वर CPU पर लोड 30% कम हो जाए। दुर्भाग्य से, उपयोगकर्ताओं द्वारा किए गए सभी अन्य लोगों के बीच इस ऑपरेशन का हिस्सा 0.1% है, इसलिए सर्वर लोड की तस्वीर में कोई महत्वपूर्ण बदलाव नहीं हुआ, और उपयोगकर्ताओं को सुधार में ध्यान नहीं दिया गया।



और पसंद है। "डॉक्टर-मरीज" सादृश्य पर लौटना:

- रोगी, अब आपके पास सामान्य तापमान और रक्त संरचना है, आप स्वस्थ हैं।

"लेकिन डॉक्टर, मुझे अभी भी बुरा लग रहा है! .."

* * *

अब ए के दृष्टिकोण के बारे में बात करते हैं। हम इसे कहेंगे, जैसा कि आप अनुमान लगा सकते हैं, "विकास": मेरे दोस्तों द्वारा आवाज उठाई जाने वाली दृष्टि डेवलपर्स के लिए काफी विशिष्ट है। "कौन है, हमारे अलावा, हमारे आवेदन को समझने में सक्षम है?", "परीक्षण है जब वे जाँचते हैं कि फॉर्म के बटन पर क्लिक किया गया है," आदि। क्यूए की उपेक्षा करना आमतौर पर उद्योग की परेशानियों में से एक है, लेकिन यह विषय एक अलग लेख के योग्य है, हम परेशान नहीं होंगे।



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



एक छोटी सी टिप्पणी। सिद्धांत रूप में, प्रदर्शन और लोड परीक्षण पर एक सलाहकार के रूप में, "विकास" दृष्टिकोण मुझे आमतौर पर "व्यवस्थापक" के रूप में कम परेशान करता है। जब सिस्टम "बर्न" करना शुरू करता है, प्रोग्रामर और एडिंस के शब्द - "सब कुछ हमारे साथ ठीक है" या "हम अब सब कुछ ठीक कर देंगे" - परियोजना प्रबंधकों को समझाने के लिए। निर्णय लोड के लिए एक अग्नि विशेषज्ञ को नियुक्त करने के लिए किया जाता है, और - वोइला - मेरे पास एक नया ग्राहक है। इसलिए, प्रिय प्रोग्रामर और एडमिनिस्ट्रेटर - अच्छा काम जारी रखें, बहुत-बहुत धन्यवाद। व्यावसायिक विराम का अंत।



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



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

* * *

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

* * *

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