View source for प्रदर्शन इंजीनियरिंग

{{Short description|Encompasses the techniques applied during a systems development life cycle}}
{{research paper|date=November 2016}}
प्रदर्शन इंजीनियरिंग प्रदर्शन के लिए [[ गैर-कार्यात्मक आवश्यकता ]]ओं (जैसे [[ throughput ]], लेटेंसी (इंजीनियरिंग), या [[ स्मृति ]] उपयोग) को पूरा करने के लिए सुनिश्चित करने के लिए सिस्टम डेवलपमेंट जीवन चक्र के दौरान लागू तकनीकों को शामिल करता है। इसे वैकल्पिक रूप से [[ प्रणाली अभियांत्रिकी ]] के भीतर सिस्टम प्रदर्शन इंजीनियरिंग, और [[ सॉफ्टवेयर इंजीनियरिंग ]] के भीतर सॉफ्टवेयर प्रदर्शन इंजीनियरिंग या [[ आवेदन प्रदर्शन इंजीनियरिंग ]] के रूप में संदर्भित किया जा सकता है।

जैसे-जैसे एप्लिकेशन की सफलता और व्यावसायिक सफलता के बीच संबंध को पहचान मिलती जा रही है, विशेष रूप से मोबाइल स्पेस में, एप्लिकेशन प्रदर्शन इंजीनियरिंग ने एक निवारक और संपूर्ण रूप ले लिया है।<ref>"Banking Industry Lessons Learned in Outsourcing Testing Services," Gartner. August 2, 2012.</ref> सॉफ्टवेयर विकास जीवन चक्र के भीतर भूमिका। जैसे, इस शब्द का प्रयोग आम तौर पर गैर-कार्यात्मक आवश्यकताओं का प्रभावी ढंग से परीक्षण करने के लिए आवश्यक प्रक्रियाओं, लोगों और प्रौद्योगिकियों का वर्णन करने के लिए किया जाता है, सेवा स्तरों का पालन सुनिश्चित करता है और तैनाती से पहले एप्लिकेशन प्रदर्शन को अनुकूलित करता है।

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

प्रदर्शन इंजीनियरिंग कई बड़े निगमों में एक अलग अनुशासन बन गया है, जिसमें अलग-अलग लेकिन सिस्टम इंजीनियरिंग के समानांतर काम किया जाता है। यह व्यापक है, जिसमें कई संगठनात्मक इकाइयों के लोग शामिल हैं; लेकिन मुख्य रूप से सूचना प्रौद्योगिकी संगठन के भीतर।

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

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

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

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

प्रदर्शन इंजीनियरिंग से संबंधित आवश्यकताओं के प्रकार गैर-कार्यात्मक आवश्यकताएं या एनएफआर हैं। जबकि एक कार्यात्मक आवश्यकता से संबंधित है कि कौन से व्यावसायिक संचालन किए जाने हैं, एक प्रदर्शन संबंधी गैर-कार्यात्मक आवश्यकता इस बात से संबंधित होगी कि व्यवसाय संचालन कितनी तेजी से परिभाषित परिस्थितियों में प्रदर्शन करता है।

=== निर्माण ===
इस चरण की शुरुआत में कई प्रदर्शन उपकरण संबंधी गतिविधियों की आवश्यकता होती है। इसमे शामिल है:
*चयनित उपकरणों के लिए विषय वस्तु विशेषज्ञों के रूप में प्रमुख विकास दल के सदस्यों की पहचान करें।
* विकास/घटक इकाई परीक्षण वातावरण के लिए एक [[ प्रोफाइलर (कंप्यूटर विज्ञान) ]] उपकरण निर्दिष्ट करें।
* विकास/घटक इकाई परीक्षण वातावरण के लिए एक स्वचालित इकाई (घटक) प्रदर्शन परीक्षण उपकरण निर्दिष्ट करें; इसका उपयोग तब किया जाता है जब विकास के तहत घटकों को चलाने के लिए अभी तक कोई जीयूआई मौजूद नहीं है।
*विकास/घटक इकाई परीक्षण वातावरण के लिए सर्वर-साइड इकाई (घटक) चलाने के लिए एक स्वचालित उपकरण निर्दिष्ट करें।
* विकास/घटक इकाई परीक्षण वातावरण के लिए एक स्वचालित बहु-उपयोगकर्ता सक्षम स्क्रिप्ट-चालित एंड-टू-एंड टूल निर्दिष्ट करें; इसका उपयोग स्क्रीन-संचालित उपयोग मामलों को निष्पादित करने के लिए किया जाता है।
*विकास/घटक इकाई परीक्षण परिवेश के लिए डेटाबेस परीक्षण डेटा लोड टूल की पहचान करें; यह सुनिश्चित करने के लिए आवश्यक है कि डेटाबेस ऑप्टिमाइज़र सही निष्पादन पथ चुनता है और आवश्यकतानुसार डेटाबेस को पुन: प्रारंभ और पुनः लोड करने में सक्षम बनाता है।
* विकास दल के लिए प्रदर्शन उपकरण तैनात करें।
*चयनित उपकरणों पर विकास टीम के सदस्यों को प्रस्तुतियाँ और प्रशिक्षण दिया जाना चाहिए।

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

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

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

एक बार जब नई प्रणाली लागू हो जाती है, तो चल रहे संचालन प्रदर्शन गतिविधियों को उठाते हैं, जिनमें निम्न शामिल हैं:
*यह प्रमाणित करना कि साप्ताहिक और मासिक प्रदर्शन रिपोर्ट इंगित करती है कि महत्वपूर्ण उपयोग के मामले निर्दिष्ट गैर-कार्यात्मक आवश्यकता मानदंड के भीतर प्रदर्शन करते हैं
*जहां उपयोग के मामले एनएफआर मानदंड से बाहर हो रहे हैं, दोष सबमिट करें
*मासिक और त्रैमासिक रिपोर्ट से अनुमानित रुझानों की पहचान करें, और तिमाही आधार पर, क्षमता नियोजन प्रबंधन गतिविधियों को निष्पादित करें

== सेवा प्रबंधन ==
परिचालन डोमेन (उत्पादन के बाद की तैनाती) में प्रदर्शन इंजीनियरिंग मुख्य रूप से तीन क्षेत्रों में केंद्रित है: आईटीआईएल#सेवा स्तर प्रबंधन, आईटीआईएल#क्षमता प्रबंधन, और आईटीआईएल#समस्या प्रबंधन।

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

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

===समस्या प्रबंधन===
समस्या प्रबंधन डोमेन के भीतर, प्रदर्शन इंजीनियरिंग अभ्यास प्रदर्शन संबंधी समस्याओं के मूल कारण को हल करने पर केंद्रित होते हैं। इनमें आमतौर पर सिस्टम ट्यूनिंग, ऑपरेटिंग सिस्टम या डिवाइस पैरामीटर बदलना, या यहां तक कि खराब डिजाइन या खराब कोडिंग प्रथाओं के कारण खराब प्रदर्शन को हल करने के लिए एप्लिकेशन सॉफ़्टवेयर को रीफैक्टरिंग करना शामिल है।

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

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

== यह भी देखें ==
* [[ जावा प्रदर्शन ]]
* मापनीयता
* [[ सॉफ्टवेयर की गुणवत्ता ]]
*[[ सॉफ्टवेयर परिक्षण ]]
* [[ वेब प्रदर्शन ]]

==संदर्भ==
{{Reflist}}
{{Refimprove|date=March 2009}}



==इस पेज में लापता आंतरिक लिंक की सूची==

*विलंबता (इंजीनियरिंग)
*सिस्टम विकास जीवन चक्र
*सूचान प्रौद्योगिकी
*सॉफ्टवेयर की रखरखाव
*व्यापार प्रक्रिया
*उदाहरण
*सॉफ्टवेयर प्रदर्शन परीक्षण
*परीक्षण मामला
*प्रदर्शन सुधारना
*भार परीक्षण
*क्षमता की योजना बनाना
*सेवा स्तर समझौता
*अनुमापकता
==आगे की पढाई==
*[https://docs.oracle.com/database/121/TGDBA/toc.htm Database Performance Tuning Guide]
*[http://www1.practicalperformanceanalyst.com Practical Performance Analyst - Performance Engineering Community & Body Of Knowledge]
*[https://web.archive.org/web/20100106151249/http://www.mindtree.com/downloads/MindTree%20-%20Performance%20Engineering%20Flyer.pdf Performance Engineering Methodology]
*[http://www-128.ibm.com/developerworks/rational/library/4215.html A Performance Engineering Strategy]
*[https://web.archive.org/web/20090227123220/http://test.cmg.org/conference/cmg2004/awards/4083.pdf A Performance Process Maturity Model]
*[https://www.amazon.com/Every-Computer-Performance-Book-Computers/dp/1482657759/ The Every Computer Performance Book]
*[http://webdiis.unizar.es/CRPetri/papers/jcampos/03_MC_SERP.pdf Exploring UML for Performance Engineering]
*[http://fortuitous.com/docs/primers/PE_Model_Intro.pdf Introduction to Modeling Based Performance Engineering]
*[http://www.ins.com/assets/A6BE9064-50DC-4E00-9B52-BA265DA722D6.pdf Leveraging ITIL to Improve Application Performance]
*[https://web.archive.org/web/20120211011904/http://channel9.msdn.com/wiki/default.aspx/PerformanceWiki.PerformanceEngineering Patterns & Practices Performance Engineering]
*[http://www.perfeng.com/papers/pdcp.pdf Performance and Scalability of Distributed Software Architectures]
*[http://www.perfeng.com/papers/bestprac.pdf Performance Engineering Best Practices (High Level)]
*[http://delivery.acm.org/10.1145/340000/336553/p189-pooley.pdf?key1=336553&key2=4989881611&coll=GUIDE&dl=GUIDE,ACM&CFID=11111111&CFTOKEN=2222222 Software Engineering and Performance: A Road-map]
*[http://fortuitous.com/docs/whitepapers/Performance_Cost.pdf The Vicious Cycle of Computer Systems Performance and IT Operational Costs]
*[http://blogs.technet.com/winserverperformance/ Microsoft Windows Server Performance Team] {{Webarchive|url=https://web.archive.org/web/20100504044406/http://blogs.technet.com/winserverperformance/ |date=2010-05-04 }}
*[https://web.archive.org/web/20131110055635/http://www.cmg.org/measureit/issues/mit23/m_23_2.html Gathering Performance Requirements]
*[http://sergeibaranov.sys-con.com/node/46513 Performance Testing Web Services: Strategies and Best Practices]
*[http://www.cmg.org/measureit/issues/mit49/m_49_12.html Performance Evaluation of an Air Traffic Control System using the Application Response Measurement (ARM) Standard]
*[http://www.diplom.de/MA-Thesis__Master-17047/Integration_of_Performance_Management_into_the_Application_Lifecycle.html Integration of Performance Management in ITIL]

{{Systems Engineering}}

{{DEFAULTSORT:Performance Engineering}}[[श्रेणी: सॉफ्टवेयर प्रदर्शन प्रबंधन]]
[[श्रेणी: सॉफ्टवेयर अनुकूलन]]


[[Category: Machine Translated Page]]
[[Category:Created On 31/12/2022]]