GCP में स्थिर IP बनाम VPN गति: तीन चर, एक परीक्षण

पता आरक्षित होने के बाद स्थानांतरण तेज़ हो गया, और निष्कर्ष खुद लिख गया। सिवाय इसके कि उसी बदलाव ने टनल को UDP से TCP पर भी ले जाया, परीक्षण को दूसरी शाम पर स्थानांतरित किया और संभवतः दूसरे ज़ोन के VM पर उतार दिया। बाहरी पता आरक्षित करना जीवनचक्र की समस्या हल करता है: यह पुनःआरंभ के दौरान एंडपॉइंट को वही रखता है। इसमें ऐसी कोई क्रियाविधि नहीं है जो पैकेट को तेज़ करे, इसलिए उस प्रयोग में गति का अंतर अन्य चरों का है, और आपके सामने निर्णय यह है कि आगे किसका परीक्षण करें।

आरक्षित पता वास्तव में क्या देता है

Compute Engine अस्थायी पतों को, जो इंस्टेंस के साथ आवंटित और मुक्त होते हैं, उन स्थिर पतों से अलग करता है जिन्हें आप आरक्षित करके रखते हैं। वह अंतर अवधारण और बिलिंग से जुड़ा है, उस पथ से नहीं जो पैकेट लेता है। स्थिर एंडपॉइंट DNS रिकॉर्ड, दूरस्थ पहुँच प्रोफ़ाइल, भागीदार अनुमति-सूचियों और फ़ायरवॉल नियमों के लिए सचमुच उपयोगी है, जिन्हें VM के पुनःआरंभ पर बदलना नहीं चाहिए।

एक आरक्षित करने के ये अच्छे कारण हैं। इनमें से कोई भी थ्रूपुट का कारण नहीं है।

स्तर, पता और परिवहन को तीन चर के रूप में रखें

Google Cloud Premium और Standard Network Service Tier भी बेचता है, और दोनों अलग-अलग सुविधा उपलब्धता के साथ इंटरनेट तक अलग रास्ते लेते हैं। स्थिर एड्रेसिंग दोनों के प्रति ऑर्थोगोनल है, इसलिए स्थिर और Premium को VM के बारे में असंबद्ध तथ्य मानें, समानार्थी नहीं। वास्तविक स्तर, क्षेत्र और किसी भी इंटरकनेक्शन या अटैचमेंट को दर्ज करें, क्योंकि वे पथ का वर्णन ऐसे करते हैं जैसे पते का लेबल कभी नहीं करेगा।

तीन चर, तीन अलग प्रयोग, अन्यथा परिणाम एक कहानी है, माप नहीं।

ऐसा परीक्षण डिज़ाइन करें जो एक प्रश्न का उत्तर दे

स्वीकृत UDP और TCP प्रोफ़ाइल की तुलना करते समय VM, पता, क्लाइंट स्थान, गंतव्य और कार्यभार स्थिर रखें। हर परिवहन के लिए सर्वर श्रोता और मेल खाते फ़ायरवॉल नियम—दोनों ज़रूरी हैं; क्लाइंट में कीवर्ड बदलकर श्रोता को अपरिवर्तित छोड़ना केवल आपके धैर्य का परीक्षण है। दोहराने योग्य स्थानांतरण का उपयोग करें और दिशा, अवधि, एकल बनाम समानांतर स्ट्रीम तथा इकाइयाँ दर्ज करें, क्योंकि MB/s और Mb/s आठ गुना भिन्न हैं।

VM के CPU पर भी नज़र रखें, क्योंकि छोटा इंस्टेंस एन्क्रिप्शन या softirq काम में नेटवर्क से बहुत पहले संतृप्त हो जाता है, और वह सीमा ठीक प्रदाता की सीमा जैसी दिखेगी।

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

UDP और TCP यांत्रिक रूप से क्यों भिन्न हैं

UDP पर OpenVPN डेटाग्राम ले जाता है और हानि संभालने का काम एप्लिकेशन के अपने परिवहन पर छोड़ देता है। TCP पर टनल की विश्वसनीय स्ट्रीम पहले से विश्वसनीय एप्लिकेशन स्ट्रीम के नीचे बैठती है, इसलिए एक खोया सेगमेंट अपने पीछे का सब कुछ रोक देता है जबकि बाहरी कनेक्शन अपने समय-सारणी के अनुसार पुनःप्रेषण करता है। यह हेड-ऑफ़-लाइन व्यवहार TCP को TCP के भीतर टनल करने का गुण है, प्रदाता की नीति नहीं। MTU और MSS का प्रबंधन भी दो मोड के बीच भिन्न है, जो उसी पथ पर फ़्रैगमेंटेशन व्यवहार बदल देता है।

इसलिए तेज़ TCP परीक्षण केवल यह सिद्ध करता है कि उस दिन उस पथ पर TCP तेज़ था, और अधिक सामान्य कुछ नहीं।

परिणाम ऐसे लिखें कि वह समीक्षा में टिके

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

पते की स्थिरता और स्थानांतरण गति दोनों एक ही परिनियोजन के लिए मायने रख सकती हैं, और उपयोगी निर्णय यह है कि हर बदलाव के साथ आप कौन-सी खरीद रहे हैं।