ग्राहकों की नजर में सॉफ्टवेयर की गति कितनी बार स्पष्ट होती है?

Question

सिद्धांत रूप में, ग्राहकों को पहले हाथ के अनुभव से सॉफ्टवेयर के प्रदर्शन में सुधार महसूस करने में सक्षम होना चाहिए।

व्यवहार में, कभी-कभी सुधार पर्याप्त रूप से ध्यान देने योग्य नहीं होते हैं, जैसे कि सुधार से मुद्रीकरण करने के लिए, ग्राहकों को आकर्षित करने के लिए विपणन में उद्धृत प्रदर्शन के आंकड़ों का उपयोग करना आवश्यक है।

हम पहले से ही कथित प्रदर्शन (जीयूआई विलंबता, आदि) और सर्वर-साइड प्रदर्शन (मशीनों, नेटवर्क, बुनियादी ढांचे, आदि) के बीच अंतर को जानते हैं।

यह कितनी बार होता है कि प्रोग्रामर को "विश्लेषण" लिखने के लिए अतिरिक्त लंबाई पर जाने की आवश्यकता होती है, जिसके लिए दर्शक साथी प्रोग्रामर नहीं, बल्कि प्रबंधक और ग्राहक होते हैं?

Answer 1

हालांकि @jwenting कुछ अच्छे बिंदु बनाता है, मुझे सामान्य मूल्यांकन से असहमत होना होगा।

एक उपयोगकर्ता अक्सर मामूली प्रदर्शन में सुधार नहीं देखता है।

उसके साथ, मैं सहमत हो सकता हूं।

जहाँ मैं असहमत हूँ इस कथन के इर्द-गिर्द घूमता हूँ:

अधिकांश अंतिम-उपयोगकर्ता का सामना करने वाले एप्लिकेशन अपना अधिकांश समय उपयोगकर्ता इनपुट के लिए प्रतीक्षा करते हैं।

अब, इससे पहले कि आप ऊपर और नीचे कूदें, मैं उस कथन से भी सहमत हूँ! हालाँकि, यह कथन एक तथ्य को अक्सर अनदेखा करता है, जो पर्याप्त रूप से यह नहीं समझते हैं कि उपयोगकर्ता वास्तव में एक प्रणाली को कैसे मानता है।

एक उपयोगकर्ता यह नोटिस करेगा कि एक एप्लिकेशन धीमा है जब उन्हें लोड करने के लिए इंतजार करना होगा। एक उपयोगकर्ता यह नोटिस करेगा जब उन्हें अपना डेटा दर्ज करने के बीच कार्यक्रम के लिए विराम देना होगा।

सॉफ्टवेयर प्रदर्शन उपयोगकर्ता के लिए स्पष्ट है जब यह सिस्टम के साथ एक प्राकृतिक और तरल पदार्थ की बातचीत को तोड़ देता है।

एक उपयोगकर्ता केवल सिस्टम प्रदर्शन को नोटिस नहीं करेगा जब यह पूरी तरह से काम कर रहा है और उपयोगकर्ता को पकड़ नहीं रहा है।

Comments

दुर्भाग्य से कुछ प्रोग्रामर को अपने उपयोगकर्ताओं की प्रतीक्षा की अपेक्षा पर खेलने की आवश्यकता महसूस होती है। मैंने दूसरे दिन इसे प्रोडक्शन कोड में देखा:Thread.Sleep(1000); //pretend this does more than change a 0 to a 1 in the database.

— बेन एल

यह उचित डेवलपर्स द्वारा कोड की समीक्षा में कदम होना चाहिए। कि, या खाद्य परिवर्तन को आगे बढ़ाने वाले लोगों को अपने निर्णय लेने के लाइसेंस को रद्द कर देना चाहिए।

— डैन मैकग्राथ

दूसरी ओर @ बनल ने अनुभव किया कि इससे पहले कि हम तेजी से बने, कुछ ऑपरेशन धीमा था, इतनी तेजी से कि उपयोगकर्ताओं ने सोचा कि कार्रवाई या तो निष्पादित नहीं हुई या विफल रही।

— पीटर बी

@BenL: शुक्र है, आधुनिक UX स्पष्ट रूप से मनमानी देरी डालने पर एनिमेशन का उपयोग करने की सिफारिश करता है।

— रॉवॉन्ग

Answer 2

कुछ प्रदर्शन एन्हांसमेंट को प्रदर्शन के रूप में नहीं देखा जाता है। ग्राहक बस नोटिस करेगा कि सिस्टम "अच्छा लगता है"।

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

Comments

हां, लेकिन इसकी सीमाएं हैं। मनुष्य एक सेकंड के दसवें हिस्से की तुलना में बहुत तेजी से चीजों को नोटिस नहीं करेगा, इसलिए 100ms या उससे कम की कोई भी प्रतिक्रिया सुनहरा है। प्रतिक्रिया से नीचे, कहते हैं, 250ms से 100ms चीजों को बहुत अधिक चिकना महसूस करने जा रहा है। 100ms से 40ms तक जाने का लगभग समान प्रभाव नहीं होगा।

— डेविड थॉर्नले

Answer 3

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

याद रखें कि अधिकांश एंड्यूसर सामना करने वाले एप्लिकेशन अपना अधिकांश समय उपयोगकर्ता इनपुट के लिए प्रतीक्षा करते हैं, उस इनपुट को संसाधित नहीं करते। इसलिए यदि आप उस बटन को क्लिक करने और स्क्रीन को अपडेट करने के लिए आवश्यक 100ms से 10% भी शेव करते हैं, तो उपयोगकर्ता मुश्किल से नोटिस करेगा क्योंकि वह उस अपडेट की गई स्क्रीन के साथ 10000 मी के बाद कुछ भी नहीं करेगा।

जो नोटिस करेगा वह सैसमैडिन है जो एक बैच की नौकरी देखता है जिसे 90 मिनट में पूरा करने में 2 घंटे लगते थे, लेकिन वह केवल यह नोटिस करेगा कि अगर उसे परिणाम के लिए इंतजार करना है और आहें भरनी है तो तेजी से वापसी उसे आधे रास्ते में रोक देती है उनकी फिल्म के माध्यम से :)

Comments

Sysadmin के दृष्टिकोण से, इसका मतलब यह भी हो सकता है कि लोड को संभालने के लिए चार सर्वर के बजाय तीन होने चाहिए, और यह महत्वपूर्ण है। उस जगह पर भी था जहाँ मैंने काम किया था जहाँ दैनिक चलाने में 18-20 घंटे लगते थे, यह मानते हुए कि कुछ भी गलत नहीं हुआ। प्रबंधक ने उस कटौती को करना पसंद किया होगा।

— डेविड थॉर्नले

हाँ, यह चरम मामले हैं। एक ऐसी जगह पर काम किया जाता है जहाँ एक नौकरी जो दिन में एक बार चलाने के लिए 36 घंटे पूरे करने के लिए आवश्यक होती है। इसे केवल "केवल" 20 घंटे की आवश्यकता के लिए रिफैक्ट करने में सक्षम था। ग्राहक खुश था :)

— jwenting

Answer 4

जैसा कि अन्य आज कहते हैं, यह वास्तविक कच्चे गति की तुलना में कथित प्रदर्शन और "फ्लुइडिटी" के बारे में अधिक है।

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

यह उन विलंबों को छिपाने में आवश्यक है जिनके बारे में आप कुछ नहीं कर सकते, इसलिए अभ्यास करना एक अच्छा कौशल है।

Answer 5

मैं बस यहाँ कूदना चाहता था और एक असामान्य मामला पेश करता था जहाँ ...।

* _{ग्राहक स्वतंत्रता के बारे में लगातार देखभाल कर रहे हैं और हर जगह परिवर्तन को नोटिस करेंगे!} ।

यह मेरे क्षेत्र में है जहां हम उत्पादन प्रतिपादन को कवर करते हैं जो ग्राहकों द्वारा स्वयं के प्रदर्शन के संदर्भ में मौत का विश्लेषण किया जाता है। एक मामूली संस्करण पर प्रदर्शन में 2% की मंदी "बग रिपोर्ट" के रूप में रिपोर्ट की जा रही मंदी के बराबर हो सकती है।

फोरम थ्रेड्स अक्सर ग्राहकों द्वारा सॉफ्टवेयर के विभिन्न संस्करणों के खिलाफ अपने दृश्यों को बेंचमार्क करने के साथ शुरू किए जाते हैं, जहां ग्राहक वास्तव में खुद डेवलपर्स से अधिक बेंचमार्किंग कर रहे हैं। "इस दृश्य को संस्करण X में रेंडर करने के लिए 1 घंटा 40 मिनट का समय लगा। इसे अब Y में 32 मिनट लगते हैं।"

"इस दृश्य को संस्करण X में लोड होने में 18 मिनट लगे, अब संस्करण Y में लोड होने में 4 मिनट लगते हैं।"

जब वे अनुकूलन लागू होते हैं, तो वे बेहद प्रशंसनीय होते हैं, और अकेले ही सॉफ्टवेयर की एक नई, बहुत महंगी उन्नयन की खरीद के लिए पर्याप्त हो सकता है, और कभी-कभी केवल 10% की कमी जैसे मामूली सुधार के साथ।

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

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

यह कितनी बार होता है कि प्रोग्रामर को "विश्लेषण" लिखने के लिए अतिरिक्त लंबाई पर जाने की आवश्यकता होती है, जिसके लिए दर्शक साथी प्रोग्रामर नहीं, बल्कि प्रबंधक और ग्राहक होते हैं?

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

Answer 6

केवल एक बार मैं भर में आ रहे हैं:

1. एक ही टाइम-फ्रेम में अधिक काम करने से सॉफ्टवेयर में सुधार होता है।
2. ऑफ़लाइन प्रतिपादन या प्रसंस्करण स्पष्ट रूप से तेज़ है, लेकिन अनदेखी नहीं है।
3. गति में वृद्धि कुछ नाममात्र की है लेकिन सुधार भविष्य की अड़चन को रोकते हैं
4. समानांतर प्रसंस्करण जो एक ही काम को एक ही गति से पूरा करता है, कई के लिए।
5. किसी भी समय ध्यान देने योग्य गति उत्पादकता को प्रभावित करती है।

Answer 7

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

एक उदाहरण: एपल प्रत्येक मैक ओएस एक्स के उन्नयन के लिए $ 130 का शुल्क लेता है। सिवाय हिम तेंदुए पर जो $ 30 बेचा जाता है। डेवलपर्स ने उस संस्करण पर कड़ी मेहनत की है, लेकिन बहुत कम सुधार हैं जो उपयोगकर्ता के दृष्टिकोण से दिखाई देते हैं। इसलिए Apple ने न्यूनतम शुल्क लगाने का फैसला किया।

Answer 8

यह कितनी बार होता है कि प्रोग्रामर को "विश्लेषण" लिखने के लिए अतिरिक्त लंबाई पर जाने की आवश्यकता होती है, जिसके लिए दर्शक साथी प्रोग्रामर नहीं, बल्कि प्रबंधक और ग्राहक होते हैं?

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

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

Comments

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

— एचएलजीईएम

Answer 9

मेरी राय है कि यदि प्रदर्शन लाभ ध्यान देने योग्य नहीं हैं, तो वे विपणन योग्य नहीं हैं। दूसरे शब्दों में, कोई ऐसे सॉफ़्टवेयर के लिए अधिक भुगतान क्यों करेगा जो सुधर नहीं रहा है?

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

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

Answer 10

यह निर्भर करता है कि आप अपने सॉफ़्टवेयर उत्पाद को किसको बेच रहे हैं।

अधिक बार तब नहीं, आपका ग्राहक दिन / दिन उपयोगकर्ता का अंत नहीं है। इसलिए अक्सर आप प्रदर्शन के मुद्दों को ठीक करने के बजाय अधिक अच्छी और चमकदार रिपोर्ट बनाते हैं। क्योंकि वास्तव में आप प्रबंधन को बेच रहे हैं, अंत उपयोगकर्ता को नहीं।

इसका मतलब है कि उस मामले में, आपको कुछ प्रदर्शन मुद्दों के लिए चिह्नित करने के लिए कड़ी मेहनत की जाएगी लेकिन उस रिपोर्ट को स्वचालित करने पर शीर्ष डॉलर बना देगा।