अपनी डिलीवरी विंडो के लिए आवश्यक उपयोगी स्थानांतरण दर की गणना करें, फिर पूरे पथ को मापें। पोर्ट क्षमता, राउंड-ट्रिप समय, TCP व्यवहार, स्टोरेज और एप्लिकेशन प्रोसेसिंग सभी परिणाम को प्रभावित करते हैं। वास्तविक समवर्तीता के साथ नियंत्रित परीक्षणों का उपयोग करें और नेटवर्क टियर चुनने से पहले उन्हें वास्तविक एप्लिकेशन के माध्यम से दोहराएं।
डिलीवरी विंडो को दर में बदलें
उपयोगी एप्लिकेशन डेटा की मात्रा और उसे वितरित करने के लिए उपलब्ध समय से शुरू करें। दशमलव इकाइयों का उपयोग करते हुए, दो घंटे में 2 TB स्थानांतरित करने के लिए प्रोटोकॉल ओवरहेड और रुकावटों की अनुमति देने से पहले लगभग 278 MB प्रति सेकंड पेलोड, या 2.22 Gbps की आवश्यकता होती है। यह अंकगणित एक योजना उदाहरण है, मापा गया सेवा परिणाम नहीं।
उन स्थानांतरणों को शामिल करें जो ओवरलैप करते हैं। एक निर्धारित निर्यात, ग्राहक डाउनलोड और बैकअप अपलोड संसाधन साझा कर सकते हैं, भले ही उनके मासिक कुल मामूली दिखें। केवल मासिक औसत नहीं, बल्कि एक व्यस्त-अवधि मॉडल लिखें। निर्दिष्ट करें कि कौन सी दिशा मायने रखती है और क्या विफल स्थानांतरण को पुनः आरंभ करना चाहिए या फिर से शुरू हो सकता है; वह व्यवहार सिस्टम द्वारा किए जाने वाले कार्य की मात्रा को प्रभावित करता है।
पोर्ट क्षमता को उपयोगी थ्रूपुट से अलग रखें
एक सर्वर पोर्ट लिंक क्षमता का वर्णन करता है। उपयोगी थ्रूपुट एक देखे गए अंतराल के दौरान आपके एप्लिकेशन द्वारा वितरित डेटा का वर्णन करता है। एन्क्रिप्शन, प्रोटोकॉल फ़्रेमिंग, पुनःप्रेषण, स्टोरेज गतिविधि और रिसीवर पर कार्य उस पथ के कुछ हिस्सों पर कब्जा कर लेते हैं। इसलिए एक सूचीबद्ध 10 Gbps पोर्ट यह स्थापित नहीं करता कि कोई एप्लिकेशन लगातार 10 Gbps पेलोड वितरित करेगा।
IETF RFC 6349 विशेष रूप से नेटवर्क पथ के परीक्षण को TCP प्रदर्शन की जाँच से अलग करता है। अपने स्वयं के निदान में इस अलगाव का उपयोग करें। पहले पुष्टि करें कि एंडपॉइंट और मार्ग उपयुक्त हैं, फिर ट्रांसपोर्ट और एप्लिकेशन की जाँच करें। खरीदे गए पोर्ट को बढ़ाना उस रिसीवर को ठीक नहीं करता जो धीरे-धीरे डेटा लिखता है या उस एप्लिकेशन को जो एक बार में एक अनुरोध संसाधित करता है।
समझें कि राउंड-ट्रिप समय क्यों मायने रखता है
TCP नियंत्रित करता है कि पावतियाँ लौटने से पहले कितना डेटा इन-फ़्लाइट रह सकता है। बैंडविड्थ-डिले प्रोडक्ट इसके लिए एक उपयोगी पैमाना देता है: दर गुणा राउंड-ट्रिप समय। 40 मिलीसेकंड राउंड-ट्रिप विलंब वाला एक काल्पनिक 10 Gbps पथ लगभग 50 MB इन-फ़्लाइट दर्शाता है। यह गणना बताती है कि उच्च-गति योजना में विलंबता और ट्रांसपोर्ट व्यवहार क्यों शामिल होते हैं।
परिणाम एक मनमाना सॉकेट सेटिंग लागू करने का निर्देश नहीं है। ऑपरेटिंग सिस्टम, कंजेशन कंट्रोल, बातचीत किए गए विंडो और वास्तविक पथ व्यवहार को प्रभावित करते हैं। ट्यूनिंग से पहले वर्तमान सॉफ़्टवेयर दस्तावेज़ीकरण सत्यापित करें और माप की जाँच करें। अधिक समानांतर कनेक्शन कुछ परिस्थितियों में समग्र थ्रूपुट में सुधार कर सकते हैं, लेकिन वे उस व्यक्तिगत स्थानांतरण के व्यवहार को भी छिपा सकते हैं जिस पर आपका एप्लिकेशन निर्भर करता है।
एक नियंत्रित परीक्षण मैट्रिक्स बनाएं
केवल उन एंडपॉइंट का उपयोग करें जिनके आप स्वामी हैं या जिनका परीक्षण करने के लिए अधिकृत हैं। परीक्षण विंडो और दर पर सहमति बनाएं ताकि अभ्यास सामान्य सेवा को बाधित न करे। iperf3 जैसे उपकरण कॉन्फ़िगर करने योग्य दिशा, अवधि और समानांतर स्ट्रीम प्रदान करते हैं; आधिकारिक दस्तावेज़ीकरण उन नियंत्रणों को परिभाषित करता है। संस्करण, एंडपॉइंट, मार्ग संदर्भ और सेटिंग्स को परिणाम के साथ रिकॉर्ड करें ताकि कोई अन्य ऑपरेटर इसे पुनः उत्पन्न कर सके।
एकल प्रवाह से शुरू करें, फिर प्रतिनिधि समवर्तीता जोड़ें। यदि एप्लिकेशन दोनों दिशाओं पर निर्भर करता है तो दोनों दिशाएँ चलाएं। यह उदाहरणात्मक मैट्रिक्स उन प्रश्नों को अलग करता है जिन्हें एकल शीर्षक परिणाम एक साथ मिला देगा। जब कच्चे परिणाम आंतरिक पते या परिचालन विवरण प्रकट करते हैं तो उन्हें निजी रखें, और केवल निर्णय के लिए आवश्यक माप प्रकाशित करें।
| परीक्षण | यह क्या जाँचता है | यह क्या सिद्ध नहीं करता |
|---|---|---|
| एक ट्रांसपोर्ट प्रवाह | एकल-प्रवाह पथ व्यवहार | समग्र एप्लिकेशन डिलीवरी |
| कई समानांतर प्रवाह | समवर्तीता और समग्र सीमाएँ | एक ग्राहक की स्थानांतरण दर |
| एप्लिकेशन स्थानांतरण | स्टोरेज, प्रोटोकॉल और सॉफ़्टवेयर एक साथ | हर डेटासेट के लिए प्रदर्शन |
| व्यस्त-अवधि पुनरावृत्ति | वास्तविक गतिविधि के तहत भिन्नता | एक स्थायी थ्रूपुट गारंटी |
परीक्षण के दौरान एंडपॉइंट देखें
दोनों सिरों पर CPU उपयोग, मेमोरी दबाव, स्टोरेज गतिविधि और त्रुटि काउंटर रिकॉर्ड करें। एंडपॉइंट अवलोकन के बिना स्थानांतरण परिणाम वास्तविक बाधा को अदृश्य छोड़ सकता है। जाँचें कि क्या एक प्रक्रिया या CPU संतृप्त है जबकि अन्य निष्क्रिय हैं। एक साथ कई सेटिंग्स बदलने से बचें, क्योंकि इससे यह पहचानना मुश्किल हो जाता है कि कौन सा समायोजन मदद करता है।
मेमोरी-आधारित परीक्षण को उस परीक्षण से अलग करें जो वास्तविक डेटा पढ़ता और लिखता है। पूर्व ट्रांसपोर्ट पथ की जाँच में मदद कर सकता है; बाद वाला एप्लिकेशन के कार्य को अधिक दर्शाता है। यदि परिणाम तीव्रता से भिन्न हों, तो स्टोरेज और प्रोसेसिंग की जाँच करें, मेमोरी-आधारित आंकड़े को डिलीवरी वादे के रूप में न मानें। जब उनका दायरा स्पष्ट हो तो दोनों माप उपयोगी हो सकते हैं।
वास्तविक पेलोड के साथ एप्लिकेशन का परीक्षण करें
एक HTTP निर्यात, एन्क्रिप्टेड प्रतिकृति स्ट्रीम और फ़ाइल-स्थानांतरण सत्र में अलग-अलग प्रोसेसिंग पैटर्न होते हैं। प्रतिनिधि फ़ाइल आकार, अनुरोध दर और एन्क्रिप्शन सेटिंग्स का उपयोग करें। जब उपयोगकर्ता उस चरण की प्रतीक्षा करता है तो पहला बाइट भेजे जाने से पहले डेटा तैयार करने में लगने वाले समय को शामिल करें। पहली प्रतिक्रिया विलंबता को पूर्णता समय से अलग करें, एक को दूसरे के रूप में रिपोर्ट न करें।
भिन्नता देखने के लिए पर्याप्त अंतरालों में परीक्षण दोहराएं, और कॉन्फ़िगरेशन बदलने से पहले एक बेसलाइन रखें। काल्पनिक 2 TB निर्यात के लिए, वास्तविक पूर्णता समय की तुलना दो घंटे की विंडो से करें और रुकावटों के लिए मार्जिन छोड़ें। बिना कारण पोर्ट क्षमता बढ़ाने के बजाय देखी गई बाधा के विरुद्ध सुधार चुनें।
कॉन्फ़िगरेशन चुनने के लिए परिणाम का उपयोग करें
उपयोगी आउटपुट साक्ष्य के साथ एक संसाधन आवश्यकता है: एक मापा गया पेलोड दर, स्वीकार्य पूर्णता समय, अपेक्षित समवर्तीता और एक ज्ञात सीमित चरण। उस आवश्यकता के विरुद्ध SwissOctet नेटवर्क वेरिएंट की तुलना करें, जिसमें ट्रैफ़िक भत्ता और CPU तथा स्टोरेज विशिष्टताएँ शामिल हैं। अकेले स्थान हर रिसीवर के लिए मार्ग या एंड-टू-एंड विलंबता निर्धारित नहीं करता।
तैनाती के बाद परीक्षण प्रक्रिया रखें। जब डेटासेट बढ़ें, सॉफ़्टवेयर बदले या उपयोगकर्ता अलग-अलग नेटवर्क पर जाएँ तो इसे पुनः उपयोग करें। एक पुनरावर्तनीय बेसलाइन प्रदर्शन घटना का निदान आसान बनाती है और कॉन्फ़िगरेशन बदलने के लिए एक पृथक गति परीक्षण या विज्ञापित अधिकतम की तुलना में अधिक ठोस कारण प्रदान करती है।
आपकी व्यावहारिक चेकलिस्ट।
- मात्रा और समय-सीमा से पेलोड दर की गणना करें।
- ओवरलैपिंग स्थानांतरण और दिशा को मॉडल करें।
- अधिकृत परीक्षण एंडपॉइंट और सीमाओं पर सहमति बनाएं।
- एक प्रवाह, समवर्तीता और एप्लिकेशन परीक्षणों की तुलना करें।
- परीक्षण के दौरान दोनों एंडपॉइंट देखें।
- एक पुनरावर्तनीय बेसलाइन और उपयोगी मार्जिन बनाए रखें।
महत्वपूर्ण विवरण।
क्या बड़ी TCP विंडो हमेशा धीमे स्थानांतरण को ठीक करती है?+
नहीं। पहले पथ और एंडपॉइंट का निदान करें। स्टोरेज, CPU, हानि और एप्लिकेशन व्यवहार हावी हो सकते हैं, और ट्रांसपोर्ट ट्यूनिंग वास्तविक सिस्टम के अनुकूल होनी चाहिए।
एकल प्रवाह और कई प्रवाह का परीक्षण क्यों करें?+
वे अलग-अलग प्रश्नों का उत्तर देते हैं। समग्र क्षमता एक स्थानांतरण की दर से अधिक हो सकती है; एप्लिकेशन की समवर्तीता तय करती है कि कौन सा परिणाम मायने रखता है।
क्या मैं किसी भी सार्वजनिक सर्वर के विरुद्ध क्षमता परीक्षण चला सकता हूँ?+
उन एंडपॉइंट का उपयोग करें जिन्हें आप नियंत्रित करते हैं या जिनका परीक्षण करने की अनुमति है। अवधि, दर और समय पर सहमति बनाएं ताकि माप असंबंधित सेवाओं को बाधित न करे।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- IETF RFC 6349: TCP थ्रूपुट परीक्षण के लिए रूपरेखा datatracker.ietf.org
- ESnet: iperf3 को आमंत्रित करना software.es.net
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।