एक बड़ा पोर्ट तभी मूल्यवान है जब एप्लिकेशन, भंडारण, प्रोसेसर, नेटवर्क पथ और रिसीवर इसका उपयोग कर सकें। वर्किंग सेट और समवर्तीता की योजना बनाएँ, प्रत्येक सीमित चरण का बेंचमार्क करें और परिचालन सीमाएँ परिभाषित करें। 40, 100 और 200 Gbps कैटलॉग लेबल पोर्ट वर्ग हैं, सार्वभौमिक स्थानांतरण या उपलब्धता गारंटी नहीं।
पोर्ट को डेटा स्केल में अनुवादित करें
दशमलव इकाइयों के साथ, 40, 100 और 200 Gbps प्रति सेकंड 5, 12.5 और 25 GB के लाइन-रेट अंकगणित के अनुरूप हैं। ये प्रोटोकॉल और कार्यान्वयन प्रभावों से पहले संदर्भ रूपांतरण हैं। वे आसपास के डिज़ाइन के पैमाने का वर्णन करते हैं, न कि मापी गई दर या यह वादा कि कोई ओरिजिन उतनी मात्रा में एप्लिकेशन सामग्री वितरित करेगा।
वितरण परियोजना के लिए, समवर्ती अनुरोधों, ऑब्जेक्ट आकारों और वर्किंग सेट का अनुमान लगाएँ। बार-बार छोटा लोकप्रिय सेट वितरित करने वाली सेवा बिना कैश किए गए संग्रहों को स्ट्रीम करने वाली सेवा से भिन्न होती है। मान्यताओं को स्पष्ट करें। उन मान्यताओं के बिना खरीदा गया बड़ा पोर्ट भंडारण, एप्लिकेशन या रिसीवर सीमाओं को अछूता छोड़ सकता है जबकि परियोजना की आवर्ती लागत बढ़ा सकता है।
| सूचीबद्ध पोर्ट वर्ग | कच्चा दशमलव रूपांतरण | योजना निहितार्थ |
|---|---|---|
| 40 Gbps | ओवरहेड से पहले 5 GB/s | सामग्री और एप्लिकेशन पथ को मापें |
| 100 Gbps | ओवरहेड से पहले 12.5 GB/s | भंडारण, समवर्तीता और प्रसंस्करण की जाँच करें |
| 200 Gbps | ओवरहेड से पहले 25 GB/s | प्रत्येक चरण और प्राप्ति क्षमता को सत्यापित करें |
वर्किंग सेट और कैश व्यवहार को मॉडल करें
पहचानें कि कौन सी सामग्री बार-बार अनुरोधित की जाती है और कौन सी माँग पर भंडारण से पढ़ी जानी चाहिए। एक गर्म कैश ऐसा परिणाम दे सकता है जिसे ठंडा स्टार्ट बनाए नहीं रख सकता। जब वे परियोजना के लिए मायने रखते हों तो दोनों स्थितियों का परीक्षण करें। डेटासेट को इतना बड़ा और इतना वास्तविक रखें कि माप उस प्रश्न का उत्तर दे जिसे आपको वास्तव में हल करना है।
लोकप्रिय रिलीज़ और पुराने संग्रह वाले एक वैध सॉफ़्टवेयर-डाउनलोड ओरिजिन की कल्पना करें। व्यस्त रिलीज़ विंडो की सामान्य संग्रह एक्सेस से तुलना करें। जहाँ वे संचालन ओवरलैप होते हैं वहाँ प्रकाशन, चेकसम जनरेशन और बैकअप ट्रैफ़िक के लिए क्षमता आरक्षित करें। यह मूल परिदृश्य एक योजना ढाँचा प्रदान करता है; यह स्थापित नहीं करता कि कोई विशेष हार्डवेयर या कैशिंग सेवा SwissOctet में शामिल है।
भंडारण को स्वतंत्र रूप से मापें
एप्लिकेशन द्वारा किए जाने वाले भंडारण संचालनों को मापकर शुरू करें। बड़ी फ़ाइलों की अनुक्रमिक रीड और कई छोटी यादृच्छिक रीड अलग-अलग सीमाएँ उजागर कर सकती हैं। fio दस्तावेज़ीकरण वर्कलोड पैरामीटर का वर्णन करता है जो उन पैटर्नों का प्रतिनिधित्व कर सकते हैं। नियंत्रित परीक्षण फ़ाइलों और सिस्टम के अनुकूल सेटिंग्स का उपयोग करें, और उत्पादन डेटा पर विनाशकारी परीक्षणों से बचें।
भंडारण लेआउट, डेटासेट आकार और परीक्षण स्थितियों को रिकॉर्ड करें। कैश किए गए डेटा से जुड़ा बेंचमार्क अंतर्निहित उपकरणों से निरंतर रीड के समतुल्य नहीं है। बाद में एप्लिकेशन के वास्तविक सामग्री पथ के साथ दोहराएँ। अधिक क्षमता स्वतः डिलीवरी दर नहीं बढ़ाती, और कई चयनित ड्राइव किसी विशिष्ट ऐरे लेआउट या मापी गई थ्रूपुट को स्थापित नहीं करते।
प्रोसेसर और कतार सीमाओं का निरीक्षण करें
उच्च स्थानांतरण दरों पर, एप्लिकेशन CPU उपयोग के साथ-साथ प्रसंस्करण और इंटरप्ट हैंडलिंग भी मायने रख सकते हैं। Linux कतारों और प्रोसेसरों में नेटवर्क कार्य वितरित करने के लिए रिसीव-साइड स्केलिंग और संबंधित तंत्रों का दस्तावेज़ीकरण करता है। उनकी उपस्थिति और व्यवहार हार्डवेयर और कॉन्फ़िगरेशन पर निर्भर करते हैं। हर सर्वर पर सामान्य ट्यूनिंग नुस्खा लागू करने के बजाय मापों की व्याख्या के लिए उन दस्तावेज़ों का उपयोग करें।
देखें कि कुल सिस्टम से पहले कोई एक CPU, वर्कर या रिसीव कतार व्यस्त हो जाती है या नहीं। जब उत्पादन सेवा उनका उपयोग करती है तो परीक्षण में एन्क्रिप्शन, संपीड़न और अनुरोध हैंडलिंग शामिल करें। एक निष्क्रिय औसत CPU संख्या किसी संतृप्त घटक को छिपा सकती है। एक बार में एक कारक बदलें और आधारभूत स्थिति बनाए रखें ताकि प्रभाव समझने योग्य हो।
सर्विंग एप्लिकेशन को सत्यापित करें
सर्वर को नेटवर्क बेंचमार्क के माध्यम से बाइट्स स्थानांतरित करने से अधिक करना चाहिए। अपने इच्छित सॉफ़्टवेयर के साथ कनेक्शन, अनुरोध पार्सिंग, प्राधिकरण, सामग्री रीड और प्रतिक्रिया पूर्णता को सत्यापित करें। Nginx अपने स्वयं के कार्यान्वयन के लिए फ़ाइल-स्थानांतरण और कनेक्शन नियंत्रणों का दस्तावेज़ीकरण करता है; अन्य सॉफ़्टवेयर की सेटिंग्स भिन्न होती हैं। जिस वास्तविक संस्करण को आप संचालित करेंगे उसका दस्तावेज़ीकरण पढ़ें।
वास्तविक समवर्तीता का परीक्षण करें और कुल आउटपुट के साथ-साथ टेल पूर्णता समय का भी निरीक्षण करें। एक बड़ी कुल संख्या ऐसे व्यक्तिगत अनुरोधों के साथ सहअस्तित्व में रह सकती है जो टाइम आउट हो जाते हैं। एक सीमा स्थापित करें जिस पर सेवा अभी भी स्वीकार्य व्यवहार करती है, फिर दिन भर हर घटक को उसके सैद्धांतिक अधिकतम पर चलाने का लक्ष्य रखने के बजाय परिचालन मार्जिन छोड़ें।
वास्तविक Transit विनिर्देशों की तुलना करें
SwissOctet के Transit परिवार देश को स्विस रखते हुए विभिन्न प्रोसेसर, मेमोरी और भंडारण आधारों को सूचीबद्ध करते हैं। सटीक योजना पढ़ें: Transit 100 SSD भंडारण सूचीबद्ध करता है, जबकि अन्य Transit आधार विनिर्देश NVMe सूचीबद्ध करते हैं। अतिरिक्त डिस्क विकल्पों के अपने लेबल होते हैं। पोर्ट वर्ग को शेष कॉन्फ़िगरेशन की समीक्षा का विकल्प न बनने दें।
वास्तविक सेवा के साथ उपलब्धता, ट्रैफ़िक शर्तों, प्रशासनिक जिम्मेदारियों और रिकवरी प्रक्रिया की भी पुष्टि करें। अनमीटर्ड ट्रैफ़िक एक ट्रैफ़िक मॉडल का वर्णन करता है, मनमानी गतिविधि की अनुमति या अपटाइम प्रतिबद्धता नहीं। उच्च-मात्रा वाले वर्कलोड को स्पष्ट परिचालन शर्तें और सामग्री वितरित करने के अधिकार चाहिए, जैसे छोटे वर्कलोड को चाहिए।
ट्रैफ़िक खोलने से पहले संचालन तैयार करें
परिभाषित करें कि कौन सामग्री प्रकाशित कर सकता है, कॉन्फ़िगरेशन बदल सकता है और ओरिजिन का प्रशासन कर सकता है। उन इंटरफ़ेसों की सुरक्षा करें, उपयोगी परिचालन माप एकत्र करें और ओवरलोड के लिए सीमाएँ निर्धारित करें। यदि एप्लिकेशन अप्रत्याशित व्यवहार करे तो ट्रैफ़िक कम करने या रिलीज़ को रोल बैक करने का तरीका रखें। एक बड़ा इंटरफ़ेस सामान्य सॉफ़्टवेयर या एक्सेस गलती के परिणामों को बढ़ा सकता है।
अधिकृत रिसीवरों और सहमत सीमाओं का उपयोग करके एक चरणबद्ध अभ्यास चलाएँ, फिर नियोजित वर्कलोड की ओर बढ़ाएँ। परिणामों, अनुत्तरित प्रश्नों और संसाधन हेडरूम को परिनियोजन रिकॉर्ड में रखें। बड़ा पोर्ट तभी चुनें जब यह प्रमाण इसका समर्थन करे; एक पूर्ण, मापा गया डिज़ाइन कैटलॉग में उपलब्ध सबसे बड़ी संख्या से अधिक उपयोगी है।
आपकी व्यावहारिक चेकलिस्ट।
- पोर्ट वर्ग को पेलोड डिलीवरी माने बिना परिवर्तित करें।
- कैश हिट, ठंडी रीड और समवर्ती अनुरोधों को मॉडल करें।
- हानिरहित परीक्षण डेटा के साथ संग्रहण का बेंचमार्क करें।
- CPU, वर्कर और नेटवर्क कतारों का निरीक्षण करें।
- सर्विंग एप्लिकेशन और रिसीवर क्षमता का परीक्षण करें।
- ट्रैफ़िक को चरणबद्ध करें और रोलबैक प्रक्रिया बनाए रखें।
महत्वपूर्ण विवरण।
क्या सबसे बड़ा पोर्ट हमेशा सबसे सुरक्षित विकल्प होता है?+
नहीं। मापी गई माँग और पूर्ण सिस्टम की सीमाओं के आधार पर चुनें। बड़ा पोर्ट अपर्याप्त संग्रहण, प्रोसेसर या एप्लिकेशन क्षमता को हल नहीं करता।
क्या हर Transit परिवार NVMe का उपयोग करता है?+
नहीं। वास्तविक योजना पढ़ें। Transit 100 का आधार विनिर्देश SSD सूचीबद्ध करता है; अन्य आधार योजनाओं और अतिरिक्त-ड्राइव विकल्पों के अपने विवरण हैं।
कैश किए गए डेटा के साथ-साथ ठंडे डेटा से परीक्षण क्यों करें?+
वे अलग-अलग परिचालन स्थितियाँ उजागर करते हैं। रिलीज़, रीस्टार्ट या बदलता वर्किंग सेट ऐसी संग्रहण गतिविधि उत्पन्न कर सकता है जिससे वार्म-कैश बेंचमार्क बचता है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Linux कर्नेल: नेटवर्किंग स्टैक में स्केलिंग docs.kernel.org
- fio: वर्कलोड और माप दस्तावेज़ीकरण fio.readthedocs.io
- Nginx: HTTP कोर मॉड्यूल nginx.org
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।