यह विभिन्न संस्थाओं के लिए सेवाओं को शुरू करने से बचने के बारे में लेखों की वर्तमान श्रृंखला में एक संक्षिप्त विषयांतर है। रात के खाने में एक दिलचस्प बातचीत ने उन विचारों को जन्म दिया, जो मैंने लिखने का फैसला किया।

आमदाल का नियम

1967 में, जीन अमदहल ने समानांतर कंप्यूटिंग के खिलाफ तर्क दिया। उन्होंने तर्क दिया कि उत्पादकता वृद्धि सीमित है क्योंकि कार्य के केवल हिस्से को समानांतर किया जा सकता है। बाकी "अनुक्रमिक भाग" का आकार अलग-अलग कार्यों में भिन्न होता है, लेकिन यह हमेशा होता है। यह तर्क अमलद के कानून के रूप में जाना गया।

यदि आप इसे आवंटित किए गए समानांतर प्रोसेसर की संख्या के आधार पर कार्य के "त्वरण" का ग्राफ बनाते हैं, तो आप निम्नलिखित देखेंगे:


यह एक टुकड़े के लिए एक स्पर्शोन्मुख ग्राफ है जिसे समानांतर नहीं किया जा सकता ("अनुक्रमिक भाग"), इसलिए अधिकतम त्वरण के लिए एक ऊपरी सीमा है

अमदल से लेकर यूएसएल तक

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

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

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

सभी डेटाबेस नोड्स एल्गोरिदम से मेल खाने और डेटा अनुक्रम को बचाने के कारण समन्वय लागत को प्रभावित करते हैं। जुर्माना तब भुगतान किया जाता है जब डेटा (लेन-देन डेटाबेस के मामले में) के रूप में या अंत में सहमत रिपॉजिटरी के मामले में डेटा पढ़ते समय।

यूएसएल प्रभाव

यदि आप प्रोसेसर की संख्या के आधार पर एक यूएसएल चार्ट बनाते हैं, तो एक हरी रेखा दिखाई देगी:


बैंगनी रेखा इंगित करती है कि Amdahl का कानून भविष्यवाणी करेगा

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

लोग अक्सर प्रोसेसर की संख्या बढ़ाना चाहते हैं और उत्पादकता में वृद्धि करना चाहते हैं। ऐसा करने के दो तरीके हैं:

1. अनुक्रमिक भाग को कम करें
2. अनुमोदन लागत कम करें

मानव समूहों में यूएसएल?

सादृश्य का प्रयास करते हैं। यदि कम्प्यूटेशनल "कार्य" एक परियोजना है, तो हम परियोजना में "प्रोसेसर" की संख्या के रूप में कार्य करने वाले लोगों की संख्या का प्रतिनिधित्व कर सकते हैं।

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

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

एक कमरे में पांच लोगों के लिए, ये लागत न्यूनतम हैं। सप्ताह में एक बार ब्लैकबोर्ड पर मार्कर के साथ पांच मिनट की ड्राइंग।

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

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

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

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

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

यूएसएल और माइक्रोसर्विसेज

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

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

इसके बारे में क्या करना है?

मेरा सुझाव: उपयोग की गई वास्तुकला, भाषा, उपकरण और टीम को देखें। इस बारे में सोचें कि सामंजस्य के लिए समय कहां खो जाता है जब लोग दुनिया के प्रणालीगत मॉडल में बदलाव करते हैं।

अंतराल के लिए देखो। सिस्टम की आंतरिक सीमाओं के बीच अंतराल और टीम के भीतर विभाजन।

परिवर्तनों का संचार करने के लिए पर्यावरण का उपयोग करें ताकि सामंजस्य प्रक्रिया सभी के लिए हो, व्यक्तिगत रूप से नहीं।

अपनी टीम के संचार को देखें। निरंतरता सुनिश्चित करने में कितना समय और प्रयास लगता है? शायद छोटे बदलाव करें और इसकी आवश्यकता कम करें?