क्या सॉफ्टवेयर को दिमाग में प्रदर्शन के साथ डिजाइन किया जाना चाहिए?

Question

क्या यह ध्यान में रखते हुए सॉफ़्टवेयर के किसी घटक या आर्किटेक्चर के डिज़ाइन पर शून्य-इन की सलाह दी जाती है? मेरा मतलब यह है कि प्रदर्शन-गहन वातावरण में डिजाइन/वास्तुकला का उपयोग कैसे किया जाना चाहिए?

घटकों को डिजाइन करते समय, क्या हमें केवल अच्छे ओओ सिद्धांतों का पालन करना चाहिए और यह सुनिश्चित करना चाहिए कि घटक 'विस्तार योग्य' है। इस तरह हम डिज़ाइन को थोड़ा सा और यहां थोड़ा सा करते हैं जब हम प्रदर्शन समस्याओं में भाग लेते हैं। यद्यपि इस तरह, हम अक्सर प्रदर्शन के मुद्दों में उतरेंगे जहां सॉफ़्टवेयर को थोड़ा सा मदद नहीं मिल सकती है।

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

नोट: ऊपर सूचीबद्ध मामलों में से कोई भी मैं प्रदर्शन समस्याओं में भाग लेने से पहले सॉफ्टवेयर के प्रदर्शन को ट्यून करने की कोशिश कर रहा हूं। प्रश्न को दोबारा वाक्यांश देने के लिए, सॉफ्टवेयर का डिज़ाइन प्रदर्शन उन्मुख होना चाहिए?

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

यह सवाल मुझे एक सप्ताह से परेशान कर दिया गया है और मैं अभी तक एक जवाब नहीं है। इसमें आपको क्या फायदा होगा?

Answer 1

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

"हमें छोटी क्षमता के बारे में भूल जाना चाहिए, समय के बारे में 9 7% कहें: समयपूर्व अनुकूलन सभी बुराइयों की जड़ है।"

Answer 2

किसी प्रोजेक्ट के डिज़ाइन में विस्तारशीलता, रखरखाव, प्रदर्शन, समय-समय-शिपिंग और अधिक संतुलन होना चाहिए।

मैं विस्तार के लिए पैकेज + उच्च स्तरीय आरेखों को डिजाइन करने का प्रयास करता हूं, फिर प्रदर्शन के लिए निम्न-स्तर को डिज़ाइन करता हूं।

Answer 3

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

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

Answer 4

मैं जब तक आप शुरुआत है कि प्रदर्शन के हर छोटा सा फर्क होगा से पता नहीं है के रूप में अच्छा वस्तु उन्मुख सिद्धांतों के साथ जाना कहेंगे।

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

Answer 5

मैं कहूंगा कि यह एक अनुभवी सॉफ्टवेयर इंजीनियर और सॉफ्टवेयर-नौसिखिया का अंतर बनाता है।

एक अनुभवी सॉफ्टवेयर इंजीनियर को हमेशा अपने डिजाइन के प्रदर्शन के मुद्दों को ध्यान में रखना चाहिए।

उदाहरण: जब आपके मॉड्यूल के अंदर ओ (एन^3) प्रदर्शन व्यवहार के साथ एक एल्गोरिदम संभव हो रहा है, तो स्थिति बढ़ सकती है, ताकि परिस्थितियों में आपका मॉड्यूल बहुत धीमा हो जाए।

बेशक, कई अंतर हैं। जब आपके पास इन-मेमोरी सरणी पर ओ (एन^3) होता है, तो डिस्क ऑपरेशन पर ओ (एन^2) के रूप में यह कम समस्याग्रस्त हो सकता है।

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

Answer 6

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

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

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

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

Answer 7

मुझे अपने पूरे दिल के साथ दूसरा जेके का जवाब होना चाहिए।

Knuth का उद्धरण कुछ छोटे डोमेन समस्याओं के बाहर वास्तविक जीवन में कुछ हद तक लागू है जिसमें वास्तुकला शामिल नहीं है।

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

अब, समाधान अवधारणात्मक रूप से सरल था - बैच में डीबी से डेटा की पुनर्प्राप्ति की अनुमति दें। इतनी बुद्धिमानी से काम करना। लेकिन मूल डिजाइन चरण में अतिरिक्त कुछ हफ्तों के काम के कारण क्या हो सकता था, उन्होंने प्रदर्शन के बारे में सोचने के लिए परेशान किया था, जो कि 3 महीने की परीक्षा में बदल गया क्योंकि हर छोटी फंक्शन, ऑब्जेक्ट और एपीआई के साथ-साथ समग्र वास्तुकला को स्पष्ट रूप से "100% डेटा वहां है "।

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

Answer 8

गोएज़ के रूप में कहा: लिखें बेवकूफ कोड: http://java.sun.com/developer/technicalArticles/Interviews/devinsight_1/

Answer 9

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

Answer 10

मुझे यह दिलचस्प लगता है कि केवल माइकल औनो ने "आवश्यकता" शब्द का उल्लेख किया।

जबकि Knuth का उद्धरण TRVTH है, यह सब आवश्यकताओं के लिए आता है। उनमें से एक स्केलेबिलिटी है? अपेक्षित भार क्या है? यदि आपका उत्तर "मुझे नहीं पता," पूछें।

यदि ये आवश्यकताएं हैं, तो अपने स्वीकृति परीक्षणों में लोड परीक्षण जोड़ें।

आप अभी भी रखरखाव के लिए डिज़ाइन करना चाहते हैं। Last Responsible Moment पर प्रदर्शन विचारों को देखें, फिर प्रोफ़ाइल - अनुमान न करें। सूक्ष्म अनुकूलन कंपनी के पैसे का अपशिष्ट है।

कभी-कभी जिम्मेदार क्षण काफी जल्दी होता है; मैं एक एंटरप्राइज़ सीआरएम सिस्टम तैयार नहीं कर रहा हूं जहां सभी डेटा डिस्क पर एक्सएमएल फाइलों के रूप में संग्रहीत किया जाता है। मैं क्या हूँ करने के लिए जा रहा है सार दृढ़ता परत है।

अंत में कोलिब्री की टिप्पणी सही है - उत्तर (सामान्य के रूप में) "यह निर्भर करता है।"

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

Answer 11

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

मैं निम्नलिखित पुस्तक rading sugges: Release It!: Design and Deploy Production-Ready Software