प्रदर्शन परीक्षण: नुकसान

मैं स्टॉक ट्रेडिंग के लिए अत्यधिक लोड किए गए अनुप्रयोगों के निर्माण में लगा हुआ हूं। डेटा की मात्रा और उपयोगकर्ताओं और प्रश्नों की संख्या के मामले में दोनों को लोड किया गया। स्वाभाविक रूप से, ऐसे अनुप्रयोगों के लिए प्रदर्शन सर्वोपरि है, और, परिणामस्वरूप, इसके परीक्षण।

पक्ष से इस परीक्षण का अवलोकन करते हुए, मैंने एक निश्चित मात्रा में जानकारी जमा की है, जो कि, जैसा कि मुझे लगता है, दिलचस्प होगा।

पहला पत्थर। रूपांतरण कारक

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

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

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

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

यहां एक अड़चन का एक उदाहरण है, एक परीक्षण (धीमी) स्थापना में प्रकट होता है, और उत्पादन में बस असंभव है। इसे "डाउनस्ट्रीम" अड़चन कहते हैं। जैसा कि यह हो सकता है, "डाउनस्ट्रीम" अड़चन हानिरहित है और परीक्षक और डेवलपर के लिए केवल अनुत्पादक नुकसान का कारण बनता है।

लेकिन क्या यह विपरीत हो सकता है, एक "अपस्ट्रीम" टोंटी संभव है, जो वास्तव में खतरनाक है और न केवल डेवलपर, परीक्षक आदि के लिए बहुत परेशानी पैदा कर सकती है, बल्कि ग्राहक को भी? यानी कल्पना करें कि परीक्षण स्थापना पर प्राप्त प्रदर्शन, हम पूरी तरह से संतुष्ट हैं। उदाहरण के लिए, हमारे पास 5 का रूपांतरण कारक है, हमें प्रति सेकंड 100,000 संचालन प्रदान करने की आवश्यकता है, परीक्षण स्थापना ने 25,000 दिए हैं। सब कुछ ठीक लगता है, क्या हम शांति से सो सकते हैं? कोई फर्क नहीं पड़ता कि कैसे! इसी तरह, ऐसी स्थिति में, एक अड़चन दिखाई दे सकती है जो एक परीक्षण स्थापना में अनिर्धारित (और मौलिक रूप से undetectable!) है। जिसके कारण, वास्तविक, प्रभावी रूपांतरण कारक 5 नहीं होगा, लेकिन 3. वह है 125,000 नहीं, बल्कि केवल 75,000 - 25% आवश्यकता से भी बदतर।

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

दूसरा पत्थर। परीक्षण आवेदन

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

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

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

तीसरा पत्थर। ब्लैक बॉक्स

परीक्षण के लिए सबसे सामान्य दृष्टिकोण को ब्लैक बॉक्स के रूप में परीक्षण के तहत आवेदन माना जाता है। परीक्षक कार्यान्वयन विवरण में शामिल नहीं हैं, व्यक्तिगत एप्लिकेशन घटकों की सुविधाओं और संबंधों को ध्यान में नहीं रखते हैं।

यह दृष्टिकोण सामान्य मामले में अच्छा है। इसके अलावा, इस सामान्य मामले की आवश्यक प्रारंभिक शर्तों में परीक्षण के लिए एक बड़ी (लगभग असीमित) राशि शामिल है। वास्तविकता में यह लगभग कभी नहीं होता है। इसके विपरीत, ज्यादातर मामलों में परीक्षक डेवलपर्स से पीछे रह जाते हैं। क्योंकि कम से कम कि डेवलपर्स अंतहीन कुछ फिर से।

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

लेख में 3 नुकसान का वर्णन किया गया है। शायद कोई अन्य अस्पष्ट प्रदर्शन परीक्षण मुद्दों के बारे में बात करना चाहेगा। आपकी प्रतिक्रिया की प्रतीक्षा है!

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