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 দ্রুততর ছিল, এর বেশি সাধারণ কিছু নয়।

ফলাফল এমনভাবে লিখুন যাতে তা পর্যালোচনা সহ্য করে

একটি সমর্থনযোগ্য সিদ্ধান্তের একটি আকার থাকে: এই প্রোফাইল, এই মেশিন আকারে, এই নেটওয়ার্ক টিয়ারে, এই পরিমাপকৃত ওয়ার্কলোড এই দিকে এই অবস্থার অধীনে ধরে রেখেছে। এর চেয়ে বিস্তৃত কিছুতে এক সন্ধ্যায় দেওয়ার চেয়ে বেশি রান দরকার। ধীরগতির ক্ষেত্রটি যদি অব্যাখ্যাত থাকে, তবে কোনো প্রদানকারীর নথি যে থ্রটল বর্ণনা করে না তা উদ্ভাবন না করে প্যাকেট ও সম্পদ প্রমাণসহ এটি একটি পর্যবেক্ষণ হিসেবে রাখুন।

ঠিকানার স্থিতিশীলতা ও স্থানান্তরের গতি একই ডিপ্লয়মেন্টের জন্য দুটিই গুরুত্বপূর্ণ হতে পারে, আর উপযোগী সিদ্ধান্ত হলো প্রতিটি পরিবর্তনে আপনি কোনটি কিনছেন।