इस लेख में विकिपीडिया के गुणवत्ता मापदंडों पर खरे उतरने के लिए सफ़ाई की आवश्यकता है। कृपया इस लेख को सुधारने में यदि आप सहकार्य कर सकते है तो अवश्य करें। इसके संवाद पृष्ठ पर कुछ सलाह मिल सकती है। (March 2009) |
इस लेख को विकिफ़ाइ करने की आवश्यकता हो सकती है ताकि यह विकिपीडिया के गुणवत्ता मानकों पर खरा उतर सके। कृपया प्रासंगिक आन्तरिक कड़ियाँ जोड़कर, या लेख का लेआउट सुधार कर सहायता प्रदान करें। (March 2009) अधिक जानकारी के लिये दाहिनी ओर [दिखाएँ] पर क्लिक करें।
|
सॉफ़्टवेयर इंजीनियरिंग में निष्पादन परीक्षण में, निष्पादन का इस परिप्रेक्ष्य में परीक्षण करना है कि किसी विशिष्ट कार्यभार के अधीन प्रणाली का कोई पहलू कितना तेज़ काम करता है। यह प्रणाली को मान्यता देने और उसके किसी अन्य गुण की गुणवत्ता को सत्यापित करने का कार्य भी कर सकता है, जैसे मापनीयता, विश्वसनीयता और संसाधनों का उपयोग. निष्पादन परीक्षण, कंप्यूटर विज्ञान के उभरते अभ्यास निष्पादन इंजीनियरिंग का एक उप-समुच्चय है, जो प्रणाली की डिज़ाइन और संरचना में निष्पादन को ऊपर उठाने का प्रयास करता है।
निष्पादन परीक्षण विभिन्न प्रयोजनों को पूरा कर सकता है। वह सिद्ध कर सकता है कि प्रणाली निष्पादन मानदंडों को पूरा करती है। यह दो प्रणालियों की तुलना कर सकता है कि किस प्रणाली का निष्पादन बेहतर है। या यह मूल्यांकन कर सकता है कि प्रणाली या कार्यभार के किस अंग की वजह से निष्पादन ख़राब रहा है। निदान के मामले में सॉफ़्टवेयर इंजीनियर, प्रॉलीफ़र जैसे उपकरणों का इस्तेमाल करते हैं ताकि परख सकें कि साधन या सॉफ़्टवेयर के कौन-से हिस्से ख़राब निष्पादन के लिए उत्तरदायी हैं या अनुरक्षित स्वीकार्य अनुक्रिया काल के लिए प्रवाह-क्षमता स्तर (और प्रवेश-द्वार) सिद्ध कर सकें. नई प्रणाली के लागत निष्पादन के लिए यह महत्वपूर्ण है कि विकास परियोजना के प्रारंभ में ही निष्पादन परीक्षण प्रयास शुरू हो जाएं और परिनियोजन तक जारी रहे. जितने विलंब से निष्पादन दोष का पता चलता है, उतना ही ज़्यादा उसके समाधान की लागत होती है। यह क्रियात्मक परीक्षण के मामले में सटीक है, लेकिन उसके कार्य-क्षेत्र की समग्र प्रकृति के कारण, उतना ही अधिक निष्पादन परीक्षण के लिए भी.
निष्पादन परीक्षण में, अक्सर अपेक्षित वास्तविक उपयोग के समान परीक्षण दशाओं का होना महत्वपूर्ण (और बहुधा व्यवस्थित करने में मुश्किल) होता है। तथापि वास्तविक व्यवहार में यह पूरी तरह संभव नहीं है। कारण यह कि उत्पादन प्रणालियों के कार्यभार की प्रकृति यादृच्छिक होती है और जबकि परीक्षण कार्यभार इस बात की नक़ल उतारने की अच्छी कोशिश करते हैं कि उत्पादन परिवेश में क्या होने की संभावना है, लेकिन इस कार्यभार परिवर्तनशीलता को यथावत् दोहराना असंभव होता है - सिवाय सबसे सरल प्रणाली में.
शिथिल-युग्मित संरचनात्मक कार्यान्वयन (उदा.: SOA) ने निष्पादन परीक्षण के साथ अतिरिक्त जटिलताओं की सृष्टि की है। उद्यम सेवाओं या संपत्तियों के लिए (जो सामान्य बुनियादी ढांचा या प्लेटफ़ॉर्म साझा करती हैं) उत्पादन-जैसी स्थितियों को सही तौर पर दोहराने के लिए (जहां सभी उपभोक्ता साझा की हुई आधारभूत संरचनाओं या प्लेटफ़ॉर्मों पर उत्पादन-जैसे आदान-प्रदान की मात्रा तैयार करते हों) समन्वित निष्पादन परीक्षण की आवश्यकता है। इस गतिविधि से जुड़ी जटिलताओं और वित्तीय तथा समय की ज़रूरतों के कारण, अब कुछ संगठन संसाधनों की क्षमता तथा अपेक्षाओं को समझने तथा उनकी गुणवत्ता विशेषताओं को सत्यापित/मान्य करने के लिए अपने निष्पादन परीक्षण परिवेशों (PTE) में ऐसे उपकरणों को उपयोग में लाते हैं जो उत्पादन-जैसी स्थितियों को (जिसे "रव" भी कहा जाता है) तैयार कर सकते हैं और उन पर निगरानी रख सकते हैं।
कई निष्पादन परीक्षण, वास्तविक निष्पादन लक्ष्यों के निर्धारण पर विचार किए बिना ही शुरू किए जाते हैं। व्यापार के नज़रिए से पहला सवाल हमेशा यह होना चाहिए कि "हम निष्पादन परीक्षण क्यों कर रहे हैं?" अनुप्रयोग प्रौद्योगिकी और उद्देश्य के आधार पर निष्पादन लक्ष्य अलग हो सकते हैं, लेकिन उनमें हमेशा निम्न में से कुछ शामिल होना चाहिए:-
यदि एक अनुप्रयोग प्रयोक्ताओं की पहचान किसी लॉगिन प्रक्रिया के ज़रिए करता है, तो संगामिति लक्ष्य अति आवश्यक है। परिभाषा के अनुसार, यह समवर्ती अनुप्रयोग प्रयोक्ताओं की सबसे अधिक संख्या है, किसी भी समय जिसका समर्थन अनुप्रयोग से अपेक्षित है। आपके लिपिबद्ध आदान-प्रदान का कार्य-प्रवाह वास्तविक अनुप्रयोग संगामिति पर असर डाल सकता है, खासकर यदि परस्पर क्रिया वाले हिस्से में लॉगिन एवं लॉगआउट गतिविधि शामिल हों.
यदि आपके अनुप्रयोग में प्रयोक्ताओं की कोई अवधारणा नहीं है, तो आपका निष्पादन लक्ष्य अधिकतम प्रवाह क्षमता या आदान-प्रदान दर पर आधारित होने की संभावना है। एक आम उदाहरण विकिपीडिया जैसे वेब साइट का आकस्मिक ब्राउज़िंग हो सकता है।
यह एक अनुप्रयोग नोड के लिए अन्य के अनुरोध पर अनुक्रिया करने में लगने वाले समय को निर्दिष्ट करता है। एक सामान्य उदाहरण होगा ब्राउज़र क्लाइंट से वेब सर्वर को HTTP 'GET' अनुरोध. अनुक्रिया काल के मामले में यही है जिसे सब लोड परीक्षण उपकरण वास्तव में मापते हैं। यह प्रासंगिक होगा कि अनुप्रयोग परिदृश्य के सभी नोड्स के बीच सर्वर अनुक्रिया काल लक्ष्य निर्धारित किए जाएं.
लोड परीक्षण उपकरणों द्वारा निपटने के लिए एक कठिन विषय, चूंकि आम तौर पर उनके पास कोई अवधारणा नहीं होती कि एक समयावधि की पहचान के अलावा नोड के भीतर क्या हो रहा है, जहां 'तार पर' कोई गतिविधि नहीं होती है। प्रतिपादन अनुक्रिया काल मापने के लिए आम तौर पर निष्पादन परीक्षण परिदृश्य के अंग के रूप में कार्यात्मक परीक्षण लिपियां सम्मिलत हों, जो एक ऐसी विशेषता है जिसकी पेशकश कई लोड परीक्षण उपकरण नहीं करते हैं।
यह निष्पादन परीक्षण का सबसे सरलतम रूप है। भार परीक्षण आम तौर पर किसी विशिष्ट अपेक्षित लोड के अंतर्गत अनुप्रयोग के व्यवहार को समझने के लिए किया जाता है। यह भार निर्धारित अवधि में विशिष्ट बार आदान-प्रदान करने वाले अपेक्षित प्रयोक्ताओं की समवर्ती संख्या हो सकती है। यह परीक्षण सभी महत्वपूर्ण व्यापार के महत्वपूर्ण आदान-प्रदान का अनुक्रिया काल देगा. यदि डेटाबेस, अनुप्रयोग सर्वर आदि की भी निगरानी की जाए, तो यह साधारण परीक्षण ही अनुप्रयोग सॉफ़्टवेयर की किन्हीं बाधाओं की ओर इंगित कर सकता है।
सामान्यतः यह परीक्षण अनुप्रयोग परिदृश्य में क्षमता की ऊपरी सीमा को समझने के लिए इस्तेमाल होता है। इस प्रकार का परीक्षण, अत्यधिक भार के समय अनुप्रयोग की मज़बूती के निर्धारण के लिए किया जाता है और अनुप्रयोग प्रशासकों को यह निर्धारित करने में मदद देता है कि क्या अपेक्षित अधिकतम सीमा से वर्तमान भार अधिक होने से अनुप्रयोग समुचित रूप से निष्पादित कर सकेगा.
यह परीक्षण आम तौर पर इस निर्धारण के लिए किया जाता है कि क्या सतत अपेक्षित भार को अनुप्रयोग संभाल पाएगा. क्षमता परीक्षण के दौरान, संभाव्य रिसाव का पता लगाने के लिए मेमोरी उपयोग पर निगरानी रखी जाती है। साथ ही निष्पादन ह्रास महत्वपूर्ण है, लेकिन अक्सर इसे अनदेखा किया जाता है। अर्थात्, यह सुनिश्चित करने के लिए कि निरंतर गतिविधि की कुछ लंबी अवधि के बाद प्रवाह क्षमता और/या अनुक्रिया काल, परीक्षण के शुरूआत की तुलना में अच्छा या बेहतर है।
जैसा कि नाम से स्पष्ट है, उपयोगकर्ताओं की संख्या की मज़बूती के परीक्षण द्वारा अनुप्रयोग के व्यवहार को समझना ही स्पाइक (कील) परीक्षण है; कि क्या निष्पादन प्रभावित होगा, अनुप्रयोग असफल होगा, या वह भार में नाटकीय परिवर्तनों को संभाल सकेगा.
विन्यास परीक्षण पारंपरिक निष्पादन परीक्षण का एक और रूपांतरण है। भार के परिप्रेक्ष्य में निष्पादन के परीक्षण की बजाय आप अनुप्रयोग निष्पादन और व्यवहार पर अनुप्रयोग परिदृश्य के विन्यास परिवर्तनों के प्रभाव का परीक्षण कर रहे हैं। एक सामान्य उदाहरण भार-संतुलन के विभिन्न तरीकों के साथ प्रयोग करना होगा.
निष्पादन परीक्षण के लिए अनन्य तो नहीं, पर इस शब्द का प्रयोग अनुप्रयोग समस्या में परिणत होने वाले परीक्षण कार्यान्वयन के दोहराव को वर्णित करने के लिए किया जाता है। अक्सर ग़लती के प्रभाव-क्षेत्र को अलग करने और पुष्टि करने के लिए इस्तेमाल होता है।
अनुप्रयोग की एक स्थिर रचना, जहां तक संभव हो जो उत्पादन परिवेश को प्रतिबिंबित करे.
निष्पादन परीक्षण परिवेश को UAT या विकास परिवेश के साथ जोड़ना नहीं चाहिए. यह संकटपूर्ण है क्योंकि यदि उसी परिवेश में एक UAT या समाकलन परीक्षण या अन्य परीक्षण किया जा रहा हो, तो निष्पादन परीक्षण से प्राप्त परिणाम विश्वसनीय नहीं हो सकते. एक उत्तम अभ्यास के रूप में हमेशा ही यह उपयुक्त होगा कि जितना संभव हो निष्पादन परीक्षण के लिए उत्पादन परिवेश जैसा एक अलग माहौल उपलब्ध हो.
कतिपय बहुत ही सामान्य मिथक नीचे दिए गए हैं।
1. निष्पादन परीक्षण प्रणाली के क्रमभंग के लिए किया जाता है।
तनाव परीक्षण प्रणाली के ब्रेक-पॉइंट को समझने के लिए किया जाता है। अन्यथा अपेक्षित प्रयोक्ता भार के अधीन अनुप्रयोग के व्यवहार को समझने के लिए आम तौर पर सामान्य लोड टेस्टिंग किया जाता है। स्पाइक लोड जैसी अन्य अपेक्षाओं के आधार पर, विस्तृत समय के निरंतर लोड के लिए स्पाइक, एंड्युरेंस सोक या स्ट्रेस टेस्टिंग की ज़रूरत होगी.
2. निष्पादन परीक्षण केवल सिस्टम इंटिग्रेशन टेस्टिंग के बाद किया जाना चाहिए.
हालांकि यह अधिकतर उद्योग का मानक है, निष्पादन परीक्षण अनुप्रयोग के प्रारंभिक विकास चरण में भी किया जा सकता है। इस तरह के दृष्टिकोण को प्रारंभिक निष्पादन परीक्षण के रूप में जाना जाता है। यह दृष्टिकोण निष्पादन मानकों को ध्यान में रखते हुए अनुप्रयोग के समग्र विकास को सुनिश्चित करेगा. इस प्रकार अनुप्रयोग को जारी करने से ठीक पहले निष्पादन बग का पता चलना और उसके सुधार में शामिल लागत को काफी हद तक कम किया जा सकता है।
3. निष्पादन परीक्षण में केवल लिपियां शामिल होती हैं और किसी भी अनुप्रयोग परिवर्तन से लिपियों के सामान्य रीफ़ैक्टरिंग की ज़रूरत होगी.
निष्पादन परीक्षण स्वयं सॉफ़्टवेयर उद्योग में एक विकासशील विज्ञान है। लिपिकरण हालांकि अपने आप में महत्वपूर्ण है, पर निष्पादन परीक्षण में वह केवल घटकों में से एक है। किसी भी निष्पादन परीक्षक के लिए बड़ी चुनौती है कार्यान्वयन हेतु जांच प्रकार का निर्धारण और निष्पादन अड़चनों को निर्धारित करने के लिए विभिन्न निष्पादन काउंटरों का विश्लेषण.
अनुप्रयोग परिवर्तन से संबंधित मिथक का दूसरा खंड कि इसके परिणामस्वरूप केवल लिपियों में थोड़ी रीफ़ैक्टरिंग की ज़रूरत होगी, भी ग़लत है, क्योंकि UI में किसी भी रूप में परिवर्तन की वजह से, खासकर वेब प्रोटोकॉल में, लिपियों को दुबारा शुरू से पुनर्विकसित करने की ज़रूरत होगी. यह समस्या बड़ी हो जाती है, अगर इसमें आवेष्टित प्रोटोकॉल में शामिल हों वेब सेवा, साइबेल, वेब क्लिक एंड स्क्रिप्ट, सिट्रिक्स, SAP.
निष्पादन परीक्षण प्रौद्योगिकी एक या अधिक PC या यूनिक्स सर्वर को इनजेक्टरों के रूप में कार्य करने के लिए तैनात करता है - जिनमें प्रत्येक असंख्य प्रयोक्ताओं की उपस्थिति का अनुकरण करते हैं और प्रत्येक ऐसे होस्ट के साथ अन्योन्य क्रिया के स्वचालित अनुक्रम को चलाते हैं, जिसके निष्पादन का परीक्षण किया जा रहा है (स्क्रिप्ट या स्क्रिप्टों की श्रृंखला के रूप में अभिलिखित, ताकि विभिन्न प्रकार के प्रयोक्ता अन्योन्य क्रियाओं का अनुकरण कर सकें). आम तौर पर, एक अलग PC परीक्षण संचालक के रूप में कार्य करता है, जो प्रत्येक इनजेक्टर से मैट्रिक्स का समन्वयन और संग्रहण करता है तथा रिपोर्टिंग के प्रयोजन से निष्पादन डाटा का मिलान करता है। सामान्य अनुक्रम है भार को बढ़ाना - आभासी प्रयोक्ताओं की एक छोटी संख्या के साथ शुरू करते हुए और कुछ अधिकतम अवधि तक संख्या को बढ़ाना. परीक्षण परिणाम दर्शाते हैं कि भार के साथ निष्पादन किस तरह बदलता रहता है, जो प्रयोक्ताओं की संख्या बनाम अनुक्रिया काल के रूप में दिया जाता है। इस तरह के परीक्षणों को निष्पादित करने के लिए विभिन्न उपकरण उपलब्ध हैं। इस श्रेणी में आम तौर पर उपकरण परीक्षणों की एक ऐसी व्यवस्था को अंजाम देते हैं, जो प्रणाली के प्रति असली उपयोगकर्ताओं का अनुकरण करता है। कभी-कभी परिणामों से कुछ विषमताएं प्रकट होती हैं, उदाहरण के लिए, जबकि औसत अनुक्रिया काल स्वीकार्य हो सकता है, वहीं ऐसे कुछ प्रमुख सर्वथा भिन्न आदान-प्रदान रहते हैं जिनको पूरा करने में काफ़ी समय लगता है - जो संभवतः अक्षम डाटाबेस प्रश्नों, चित्रों आदि की वजह से हो.
निष्पादन परीक्षण को तनाव परीक्षण के साथ संयुक्त किया जा सकता है, ताकि देख सकें कि जब एक स्वीकार्य भार अधिक हो जाता है - तो क्या सिस्टम क्रैश होता है? अगर भारी बोझ को कम किया जाए, तो ठीक होने में कितना समय लगता है? क्या यह इस तरह विफल होता है कि संपार्श्विक क्षति पहुंचती है?
विश्लेषणात्मक निष्पादन मॉडलिंग एक स्प्रेडशीट में अनुप्रयोग के व्यवहार मॉडल करने की एक पद्धति है। मॉडल को आदान-प्रदान संसाधन अपेक्षाओं का माप पहुंचाया जाता है (CPU, डिस्क I/O, LAN, WAN), जिसे आदान-प्रदान मिश्रण (व्यापार लेन-देन प्रति घंटा) द्वारा मापा जाता है। मापे गए आदान-प्रदान संसाधन मांग को घंटेवार संसाधन मांग का पता लगाने के लिए जोड़ा जाता है और संसाधन भार के प्राप्त करने के लिए घंटेवार संसाधन क्षमता से विभाजित किया जाता है। अनुक्रिया काल सूत्र (R=S/(1-U), R=अनुक्रिया काल, S=सेवा काल, U=भार) का उपयोग करते हुए अनुक्रिया समय की गणना की जा सकती है और निष्पादन परीक्षणों के परिणामों के साथ अंशशोधित किया जा सकता है। विश्लेषणात्मक निष्पादन मॉडलिंग, वास्तविक या प्रत्याशित कारोबारी उपयोग के आधार पर डिज़ाइन विकल्पों के मूल्यांकन और प्रणाली का आकार घटाने की अनुमति देता है। इसलिए यह निष्पादन परीक्षण से ज़्यादा तेज़ और सस्ता है, हालांकि इसके लिए हार्डवेयर प्लेटफॉर्म को पूरी तरह से समझने की आवश्यकता है।
यह निष्पादन विनिर्देशों (आवश्यकताओं) को निर्दिष्ट करने और किसी निष्पादन परीक्षण योजना में उनके प्रलेखन के लिए महत्वपूर्ण है। आदर्श रूप में, इसे किसी डिज़ाइन प्रयास से पहले, किसी प्रणाली विकास परियोजना के विकास चरण की आवश्यकताओं के दौरान किया जाता है। अधिक जानकारी के लिए निष्पादन इंजीनियरिंग देखें.
हालांकि, निष्पादन परीक्षण को अक्सर किसी विनिर्देशन के प्रति निष्पादित नहीं किया जाता अर्थात् किसी ने अभिव्यक्त नहीं किया होगा कि प्रयोक्ताओं की किसी विशिष्ट संख्या के लिए अधिकतम स्वीकार्य अनुक्रिया काल क्या होना चाहिए. निष्पादन परीक्षण का उपयोग अक्सर निष्पादन प्रोफ़ाइल ट्यूनिंग की प्रक्रिया के हिस्से के रूप में किया जाता है। यहां विचार "कमज़ोर कड़ी" की पहचान से है - निश्चित रूप से प्रणाली का कोई तो हिस्सा है, जिसे यदि तेज़ी के साथ अनुक्रिया करने के लिए व्यवस्थित किया जाता है, तो परिणामतः समग्र प्रणाली तेजी से चल सकती है। कभी-कभी यह पहचानना एक कठिन कार्य होता है कि प्रणाली का कौन-सा हिस्सा इस महत्वपूर्ण मार्ग का प्रतिनिधित्व करता है और कुछ परीक्षण उपकरणों में इनस्ट्रूमेंटेशन शामिल होता है (या इनस्ट्रूमेंटेशन उपलब्ध कराने वाले एड-ऑन हो सकते हैं) जो सर्वर (एजेंट) पर चलता है और आदान-प्रदान समय, डाटाबेस अभिगम समय, उपरि नेटवर्क और अन्य सर्वर मॉनिटर की रिपोर्ट देते हैं, जिनका कच्चे निष्पादन आंकड़ों के साथ विश्लेषण किया जा सकता है। इस तरह के उपकरण के बिना किसी एक को सर्वर पर Windows टास्क प्रबंधक पर यह देखने के लिए झुके रहना होगा कि निष्पादन परीक्षण कितना CPU लोड सृजित कर रहे हैं (विंडोज़ प्रणाली को परीक्षणाधीन मानते हुए).
एक ऐसी कंपनी का क़िस्सा है जिसने समस्या का उचित विश्लेषण किए बिना ही अपने सॉफ़्टवेयर के अनुकूलन के लिए एक बड़ी राशि खर्च की. अंततः उन्हें प्रणाली के ‘निष्क्रिय लूप’ को दुबारा लिखना पड़ा, जहां उन्होंने पाया कि प्रणाली का अधिकांश समय खर्च होता है, पर फिर भी दुनिया के सबसे कुशल निष्क्रिय लूप के साथ, जाहिर है समग्र निष्पादन में एक कण भी सुधार नहीं हुआ!
निष्पादन परीक्षण को वेब भर में निष्पादित किया जा सकता है और यहां तक कि देश के विभिन्न भागों में किया जा सकता है, क्योंकि यह माना जाता है कि इंटरनेट का ही अनुक्रिया काल क्षेत्रवार बदलता रहता है। इसे कार्यालय के भीतर भी किया जा सकता है, हालांकि तब सार्वजनिक नेटवर्क पर समान्यतः लागू होने के समान, अंतराल को प्रवेश कराने के लिए रूटर्स के विन्यास की ज़रूरत होगी. यथार्थवादी बिंदु से भार को प्रणाली में प्रवर्तित करना चाहिए. उदाहरण के लिए, यदि प्रणाली के 50% प्रयोक्ता आधार 56K मॉडेम कनेक्शन के ज़रिए प्रणाली तक पहुंच रहे हों और शेष आधे T1 के ज़रिए, तो लोड इनजेक्टर (कंप्यूटर जो वास्तविक प्रयोक्ताओं का अनुकरण करते हैं) उन्हीं कनेक्शनों पर भार पहुंचाएं (आदर्श) या उसी प्रयोक्ता प्रोफ़ाइल का अनुसरण करते हुए, ऐसे कनेक्शनों की नेटवर्क अव्यक्तता का अनुकरण करें.
प्रयोक्ताओं की संभाव्य चरम संख्या के बारे में बयान हमेशा मददगार साबित होगा, जिनके द्वारा व्यस्ततम समय में प्रणाली के उपयोग की संभावना है। यदि ऐसा बयान भी मिल जाए कि अनुक्रिया काल का अधिकतम अनुमेय 95 प्रतिशत किससे गठित है, तो एक इनजेक्टर विन्यास का उपयोग यह जांचने के लिए किया जा सकता है कि क्या प्रस्तावित प्रणाली उस विनिर्देशन को पूरा करती है।
निष्पादन विनिर्देशनों द्वारा कम से कम निम्नलिखित प्रश्न पूछे जाने चाहिए:
ऐसे परीक्षण के लिए किए जाने वाले कार्यों में शामिल होंगे:
Microsoft डेवलपर नेटवर्क के अनुसार Performance Testing Methodology में निम्नलिखित गतिविधियां शामिल होती हैं: