क्षमता अनुमानक

आपको वास्तव में कितने सर्वर चाहिए? अंदाज़े के बजाय अंकगणित से जवाब दें: अनुमानक को अपनी अनुरोध दर, प्रत्येक अनुरोध द्वारा जलाया गया CPU समय और उपयोगकर्ताओं को दिखने वाला प्रतिक्रिया समय दें, और यह लौटाता है कि ट्रैफ़िक कितने कोर व्यस्त रखता है, प्रावधान करने के लिए पूरे सर्वर — आपकी अतिरेक नीति लागू करके —, आपके कनेक्शन पूलों को जिस समवर्तीता से बचना होगा, और वही सेवा दो, पाँच और दस गुना ट्रैफ़िक पर कैसी दिखती है।

सूत्र, सरल भाषा में

कोर। अनुरोध दर को प्रत्येक अनुरोध द्वारा खपत किए गए CPU सेकंड से गुणा करें: यही वह संख्या है जितने कोर ट्रैफ़िक 100% पर व्यस्त रखता है। फिर अपने लक्ष्य उपयोग से भाग दें — 70% पर, आपके द्वारा प्रावधान किया गया प्रत्येक कोर योजना के केवल 0.7 कोर के रूप में गिना जाता है, और अन्य 0.3 वह गुंजाइश है जो ट्रैफ़िक डगमगाने पर कतारें छोटी रखती है। आवश्यक कोर = अनुरोध/सेकंड × प्रति अनुरोध CPU सेकंड ÷ लक्ष्य उपयोग।

सर्वर। कोर को प्रति सर्वर कोर से भाग दें और ऊपर की ओर पूर्णांकित करें — सर्वर का 0.4 जैसी कोई चीज़ नहीं होती, और नीचे की ओर पूर्णांकित करना वह तरीका है जिससे औसत पर काम करने वाली योजना शिखर पर विफल होती है। अतिरेक उसके बाद लागू होता है: N+1 पूर्णांकित गिनती में एक अतिरिक्त सर्वर जोड़ता है; 2N पूरे बेड़े को दोगुना कर देता है। समवर्तीता Little's law से आने वाली एक अलग संख्या है: प्रगति में अनुरोध = अनुरोध/सेकंड × सेकंड में प्रतिक्रिया समय। यह थ्रेड पूल, डेटाबेस कनेक्शन और फ़ाइल विवरणकों का आकार तय करती है — वे सीमाएँ जिनसे सेवाएँ वास्तव में टकराती हैं जबकि उनके CPU अभी भी आराम कर रहे होते हैं। निर्गम, जब आप प्रतिक्रिया आकार देते हैं, अनुरोध/सेकंड × आकार × 8 होता है, वे बिट्स जिनसे आपका नेटवर्क बिल बना है। साथी लेख, आपको वास्तव में कितने सर्वर चाहिए, बताता है कि प्रत्येक इनपुट कहाँ से आता है और विक्रेता बेंचमार्क इन सबसे क्यों असहमत होते हैं।

योजना के साथी: SLA त्रुटि बजट कैलकुलेटर उस उपलब्धता लक्ष्य को मिनटों में बदलता है जिसकी यह क्षमता रक्षा करती है, और बैकअप प्रतिधारण कैलकुलेटर उसी सिस्टम के संग्रहण पक्ष का आकार तय करता है।

अक्सर पूछे जाने वाले प्रश्न

100% के बजाय 70% उपयोग के लिए योजना क्यों बनाएँ?

क्योंकि कतारें संतृप्ति पर नहीं, उससे पहले फटती हैं। औसतन 95% व्यस्त CPU वह CPU है जिसकी कतार हर बार ट्रैफ़िक डगमगाने पर बिना सीमा के बढ़ती है — और ट्रैफ़िक हमेशा डगमगाता है। उपयोग लक्ष्य वह गुंजाइश है जो शिखरों, परिनियोजनों, पुनः प्रयासों और एक धीमी निर्भरता को सोखती है। सत्तर प्रतिशत विलंबता-संवेदनशील सेवाओं के लिए उद्योग का डिफ़ॉल्ट है; देरी सहन करने वाले बैच वर्कर अधिक गर्म चल सकते हैं, और उपयोगकर्ता-सामने वाली तथा उछाल वाली हर चीज़ को अधिक ठंडा चलना चाहिए।

कोर और प्रगति में अनुरोधों में क्या अंतर है?

वे अलग-अलग प्रश्नों के उत्तर देते हैं। कोर CPU सेवा समय से आते हैं: प्रत्येक अनुरोध कितना प्रोसेसर खपत करता है। प्रगति में अनुरोध Little's law से आते हैं: दर को प्रतिक्रिया समय से गुणा किया गया, और वे समवर्तीता मापते हैं — कनेक्शन, थ्रेड, खुली रखी गई स्मृति — प्रोसेसर भार नहीं। धीमी डाउनस्ट्रीम कॉलों वाली सेवा दो कोर का उपयोग करते हुए 500 अनुरोध प्रगति में रख सकती है, और उसका कनेक्शन पूल CPU समाप्त होने से बहुत पहले समाप्त हो जाएगा। दोनों का आकार तय करें, या जिसे आपने अनदेखा किया वह आउटेज बन जाएगा।

मेरा लोड परीक्षण कहता है कि एक सर्वर प्रति सेकंड 2,000 अनुरोध संभालता है। यह अनुमानक असहमत क्यों है?

लोड परीक्षण आमतौर पर एक गर्म, स्थिर, कैश-गर्म सेवा को मापते हैं जो एक उदार क्लाइंट से एक ही अनुरोध आकार का उत्तर देती है। उत्पादन कोल्ड स्टार्ट, TLS हैंडशेक, पुनः प्रयास, धीमे अनुरोधों की लंबी पूंछ, शोरगुल वाले पड़ोसी और वह परिनियोजन जोड़ता है जो दस मिनट के लिए क्षमता आधी कर देता है। अनुमानक जानबूझकर रूढ़िवादी है — औसत CPU समय, उपयोग की एक छत, पूरे सर्वर, जोड़ा गया अतिरेक। लोड परीक्षण को संभव की छत और इस संख्या को प्रावधान करने की फ़र्श मानें; योजना के लिए सत्य फ़र्श है।

N+1 वास्तव में किससे रक्षा करता है?

एक विफलता से: एक मृत होस्ट, रोटेशन से हटाया गया एक ख़राब परिनियोजन, एक उपलब्धता क्षेत्र घटना जो एक एकल इंस्टेंस को ले जाती है। N+1 के साथ, शेष N सर्वर फिर भी लक्ष्य पूरा करते हैं — पहले ट्रैफ़िक से N का आकार तय करने और बाद में अतिरिक्त जोड़ने का यही अर्थ है। 2N एक अलग वादा है: दो पूर्ण प्रतियाँ, आमतौर पर क्षेत्रों के पार, उन सेवाओं के लिए जिन्हें एक पूरी प्रतिलिपि खोने पर भी जीवित रहना होगा। यह बिल दोगुना कर देता है, इसलिए इसे उन सेवाओं के लिए ख़रीदा जाता है जिनकी अनुपस्थिति सुर्खियों में मापी जाती है।

मुझे प्रति अनुरोध मेरा CPU सेवा समय कैसे मिले?

इसे मापें, इसका अनुमान न लगाएँ। एक चलती सेवा पर: एक विंडो में खपत किए गए कुल CPU सेकंड, उसी विंडो में सेवा किए गए अनुरोधों से विभाजित। एप्लिकेशन प्रदर्शन निगरानी उपकरण इसे प्रति अनुरोध CPU के रूप में सीधे रिपोर्ट करते हैं; Linux पर आप इसे /proc में प्रक्रिया CPU समय या अपने कंटेनर मेट्रिक्स से निकाल सकते हैं। अपने सबसे व्यस्त यथार्थवादी घंटे की संख्या का उपयोग करें, पूरे दिन के औसत का नहीं — औसतों से योजनाबद्ध क्षमता ठीक उसी शिखर पर विफल होती है जिसके लिए उसे ख़रीदा गया था।