OpenVPN-এর কতটি কোর দরকার? তা পথের উপর নির্ভর করে
একটি প্রবাহ একটি কোরকে ব্যস্ত রাখতে পারে, যদিও সার্ভারটি নিষ্ক্রিয় দেখায়। ব্যবহারকারী-স্থানের পথটিকে কার্নেল অফলোডের সঙ্গে তুলনা করুন, তারপর আপনি যে সমবর্তিতা সত্যিই পরিবেশন করেন তা মাপুন।
একই প্রসেসর সংখ্যার দুটি সার্ভার খুব ভিন্ন থ্রুপুট ধরে রাখতে পারে, কারণ গুরুত্বপূর্ণ সংখ্যাটি হলো সক্রিয় ডেটা পথটি আসলে কতটি কোর ব্যবহার করতে পারে। একটি ক্লায়েন্টের প্যাকেট প্রক্রিয়া করা একটি একক ব্যবহারকারী-স্থান ডেমন একটি কোরেই সীমাবদ্ধ, আর অফলোড করা কার্নেল পথ সেই কাজ ভাগ করতে পারে। কোনোটিই বলে না একটি নির্দিষ্ট মেশিন আপনার ট্রাফিকের জন্য কী করবে, তাই কোর গোনার আগে মাপ আসে।
নিচের তুলনাটি প্যাকেট কোথায় প্রক্রিয়া হয় তা নিয়ে, কোন পণ্যটি বিমূর্তভাবে দ্রুততর তা নিয়ে নয়। এগুলো আলাদা প্রশ্ন এবং আলাদা উত্তর।
ব্যবহারকারী-স্থানের পথে প্রতি প্রবাহে একটি কোর
একটি চিরাচরিত Community OpenVPN ইনস্ট্যান্সে ডেটা চ্যানেল ব্যবহারকারী-স্থানে প্রক্রিয়া হয়, এবং একটি ব্যস্ত সংযোগ একটি প্রসেসর দখলে রাখতে পারে, অথচ সামগ্রিক মেশিন ব্যবহার উল্লেখযোগ্য থাকে না। এজন্যই যে হোস্ট ইতিমধ্যেই এক প্রবাহে স্যাচুরেটেড, সেখানে কোর যোগ করলে কিছুই বদলায় না: শিডিউলারের সেই কাজ ভাগ করার কোনো উপায় নেই। প্রতি-ক্লায়েন্ট কাঠামো একজন ক্লায়েন্টের স্থানান্তরকে একটি কোরের ক্ষমতার মধ্যে বেঁধে রাখে, মোট কোর সংখ্যা যাই হোক। পরীক্ষার সময় সামগ্রিক সংখ্যার বদলে প্রতি-কোর ব্যবহার পড়ুন, নইলে বাধাটি বাড়তি ধারণক্ষমতার মতো দেখাবে।
এক হোস্টে কয়েকটি সার্ভার ইনস্ট্যান্স চালালে আলাদা ক্লায়েন্ট প্রসেসগুলিতে ছড়িয়ে যায়। এটি একটি বিদ্যমান সংযোগ সমান্তরাল করে না, এবং আলাদা পুল, শ্রোতা ও রাউটিং সিদ্ধান্তের খরচ বহন করে।
অন্য পথ: কার্নেলে প্যাকেট
ডেটা চ্যানেল অফলোড সমর্থিত প্যাকেট প্রক্রিয়াকরণ ও ক্রিপ্টোগ্রাফি কার্নেলে নিয়ে যায়, যেখানে কাজটি কয়েকটি কোর ব্যবহার করতে পারে। এটি ধারণক্ষমতার প্রশ্নটি এক কোর থেকে মেশিনে বদলায়, কিন্তু কেবল সেই কনফিগারেশনের জন্য যেগুলো বাস্তবায়ন সমর্থন করে: উপযুক্ত কার্নেল মডিউল, উপযুক্ত ডেটা সাইফার এবং অফলোড যেসব বৈশিষ্ট্য বাদ দেয় সেগুলো ছাড়া কনফিগারেশন। মডিউল ইনস্টল করা এর ব্যবহারের সমান নয়, তাই সংযোগের নিজের লগ বা স্টেটাস আউটপুট থেকে সক্রিয় মোড নিশ্চিত করুন। সংস্করণের ব্যানার প্রমাণ করে কী পাওয়া যায়, কী চলছে তা নয়।
অফলোড প্রমাণীকরণ বা নিয়ন্ত্রণ চ্যানেল সরায় না, এবং সব ডিপ্লয়মেন্টকে বহু-কোর করে তোলে না। এটি একটি উপযুক্ত ডেটা পথের স্থানীয় ত্বরণ, এবং প্রয়োজনীয়তাগুলো প্ল্যাটফর্ম ও সংস্করণভেদে ভিন্ন।
তুলনাটি আসলে কী সিদ্ধান্ত দেয়
আসল সিদ্ধান্ত হলো প্রতি-প্রবাহে একটি সীমা মেনে নেওয়া, ক্লায়েন্টদের ইনস্ট্যান্সে ছড়ানো এবং একটি সমর্থিত অফলোড কনফিগারেশনে যাওয়ার মধ্যে। প্রত্যেকে আলাদা সমস্যার সমাধান করে, আর ভুলটি বেছে নিলে সংখ্যা না সরিয়েই টাকা খরচ হয়। আসল পরীক্ষা হলো সেটি, যা সেবাটি যেভাবে ব্যবহৃত হয় সেভাবে গঠিত।
তিনটি আকার মাপুন: একটি স্থানান্তরসহ একজন ক্লায়েন্ট, কয়েকটি প্রবাহসহ একজন ক্লায়েন্ট, এবং একসঙ্গে কয়েকজন ক্লায়েন্ট। তৃতীয়টির বেশি মোট প্রমাণ করে না একটি ডাউনলোড তা পৌঁছাতে পারে, আর ধীর একক স্থানান্তর প্রমাণ করে না সার্ভারের সামগ্রিক ধারণক্ষমতা ফুরিয়েছে। ফলাফল আলাদা প্রশ্নের উত্তর দেয় এবং দুটোই রাখার যোগ্য।
কেবল মধ্যবর্তী আকারটিই বলে একজন ক্লায়েন্টের ভিতরের সমবর্তিতা সহায়ক কি না, যা সাধারণত সার্ভারের নয়, পরিবহন ও পথের বৈশিষ্ট্য। কেবল প্রথমটিই বলে একটি অ্যাপ্লিকেশন যে সীমা দেখবে। তুলনাটি অর্থবহ হতে চালানগুলোর মধ্যে কাজের চাপ একই রাখুন।
মাপুন যাতে সংখ্যাটির অর্থ থাকে
সার্ভার ও ক্লায়েন্ট সংস্করণ, সক্রিয় ডেটা পথ, সমঝোতায় ঠিক হওয়া ডেটা সাইফার, স্থানান্তরের দিক, প্যাকেটের আকার, প্রবাহের সংখ্যা ও সময়কাল লিপিবদ্ধ করুন। প্রতি-কোর সক্রিয়তা এবং দুই প্রান্তে প্যাকেট ও কিউ ড্রপ দেখুন, কারণ ক্লায়েন্টের নিজের ইন্টারফেস, প্রদানকারীর নেটওয়ার্ক বা গন্তব্য সেবা আগে সীমা হয়ে উঠতে পারে। একবারে একটি চলক বদলান, কারণ সাইফার, সংকোচন, MTU ও অফলোড একসঙ্গে বদলানো একটি চালান কোনটি গুরুত্বপূর্ণ ছিল তা বলতে পারে না। পরীক্ষার সময় আপনি সত্যিই যে প্রবেশ নীতি প্রয়োগ করতে চান তা ধরে রাখুন, কারণ কেউ চালাবে না এমন ল্যাব ব্যবস্থা কম প্রমাণ করে।
তারপর নিয়ন্ত্রণ চ্যানেলের জন্য, পুনরায় সমঝোতার জন্য এবং হোস্টে চলা বাকি সবকিছুর জন্য কিছু জায়গা রেখে দিন।
প্রত্যাশিত সমবর্তিতার অধীনে কনফিগারেশনটি কী ধরে রেখেছে তা জানান, কারও হার্ডওয়্যার থেকে অনুমান করা হারের বদলে। পরীক্ষার শর্তসহ একটি সংখ্যা কাজে লাগে; সেগুলো ছাড়া একটি প্রতিশ্রুতি এমন এক অনুমান যা আপনাকে ফিরিয়ে উদ্ধৃত করা হবে।