ব্যবহারকারী নাকি থ্রুপুট? বাস্তব লোডের জন্য VPN সার্ভার মাপা

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

অ্যাকাউন্ট সংখ্যাকে ব্যস্ত সময়ের সঙ্গে তুলনা করুন

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

দিক নির্ধারণ করে কোন লিংকটি গুরুত্বপূর্ণ। বাড়ির আপলিংক বিরলভাবেই প্রতিসম হয়, আর সারা দিন ডাউনলোড করা শাখা গেটওয়ে ঘামার অনেক আগেই তার ডাউনস্ট্রিম সীমায় পৌঁছে যায়। প্রতিটি কাজের পাশে দিক ও টানেলের পরিধি লিখে রাখুন, কারণ কেবল ব্যক্তিগত গন্তব্য বহন করা গেটওয়ে আর সমস্ত ইন্টারনেট ট্রাফিক বহন করা গেটওয়ে দুটি ভিন্ন মাপার সমস্যা।

পটভূমির লোড আলাদা সারি হিসেবে যোগ করুন: ক্লায়েন্ট আপডেট, টেলিমেট্রি এবং ফরওয়ার্ডিং ছাড়া হোস্ট যা কিছু করে। এই বাইটগুলো ভুলে যাওয়া সহজ, আর একই ইন্টারফেসই সেগুলো গোনে।

লিংকের আগেই যে সম্পদ ফুরায় তা খুঁজুন

লিংক কেবল একটি প্রার্থী। একটি টানেলের ক্রিপ্টো কাজ একটি কোর আটকে রাখতে পারে, অথচ ইন্টারফেস অর্ধেক খালি বসে থাকে; আর ভরা কিউ এমন থ্রুপুটে কল ব্যবহারের অযোগ্য করে দিতে পারে যা গ্রাফে মাঝারি দেখায়। এক ধীর রুট দূরের কোনো গন্তব্যও ক্লায়েন্টের জায়গা থেকে গেটওয়ের দুর্বলতা বলে মনে হতে পারে। তিনটি পর্যবেক্ষণ এই কেসগুলো আলাদা করে, এবং কোনোটিরই বার্স্ট পরীক্ষা দরকার নেই।

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

তারপর ঐচ্ছিক কাজ বন্ধ রেখে চালানটি আবার করুন। ব্যাকআপ থামলে যে সীমা সরে যায়, সেটি কখনও গেটওয়ের সীমা ছিল না।

তুলনাটিকে রূপান্তর করুন এমন সংখ্যায় যা আপনি যুক্তি দিয়ে রক্ষা করতে পারেন

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

প্রতি কোর ব্যবহারকারীর সংখ্যা এই অনুশীলনের সবচেয়ে কম বহনযোগ্য সংখ্যা, কারণ এটি এমন প্রোটোকল মিশ্রণ ও ডিভাইস প্রোফাইল ধরে নেয় যা পরের সাইট ভাগ করে না। মাপটি রাখুন, সূত্রটি বাদ দিন। কেউ যদি আরও পঞ্চাশ জন ব্যবহারকারীর ধারণক্ষমতা চায়, সৎ উত্তর হলো সেই পঞ্চাশ জনের ব্যস্ত-সময়ের প্রোফাইল, কোনো গুণ নয়।

থ্রুপুটের পাশাপাশি প্রতিক্রিয়া সময়ও লিখে রাখুন। যে ধারণক্ষমতা কেবল বাল্ক ট্রান্সফার রক্ষা করে, তা কল করা মানুষের জন্য ধারণক্ষমতা নয়, আর পরের পর্যালোচনা এই পার্থক্য সম্পর্কে জিজ্ঞাসা করবে।

উল্লম্বভাবে বাড়ানো আর ভূমিকা ভাগ করার মধ্যে বেছে নিন

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

সেই বিকল্পগুলোকে একে অপরের সঙ্গে নয়, রেকর্ড করা সংখ্যার সঙ্গে তুলনা করুন। যে পরিবর্তন এমন সম্পদ দ্বিগুণ করে যা সীমাবদ্ধতা ছিল না, তা হলো লাভহীন খরচ, আর রেকর্ডই আপনাকে তর্ক ছাড়া তা বলার সুযোগ দেয়। পরিবর্তনের পরে একই লোড দিয়ে আবার মাপুন, নইলে আপনি এক অনুমানকে অন্য অনুমান দিয়ে বদলে ফেলেছেন।