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

আপনি যে সংখ্যাটি পড়েছিলেন সেটি ভুল দিকে ছিল

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

এনক্যাপসুলেশন ওভারহেড এবং যেকোনো প্রতিযোগী ট্রাফিক একই বাজেটের একটি অংশ খরচ করে। কেবল ক্লায়েন্ট মাপে এমন স্পিড টেস্টে এর কোনোটিই দেখা যায় না।

পথটিকে বাজেট হিসেবে লিখুন

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

20 Mbit/s সার্ভার আপলিংক এবং 100 Mbit/s ক্লায়েন্ট ডাউনলিংক নিয়ে সার্ভার ক্লায়েন্টের লক্ষ্য করার অনেক আগেই স্থানান্তর সীমিত করে। ওভারহেড এবং কোনো সমবর্তী স্থানান্তর আরও একটি অংশ নেয়, আর সম্পৃক্ত আপলিংক স্বীকৃতিও বিলম্বিত করে, যা TCP স্থানান্তরকে কাঁচা সিলিংয়ের নিচে নামিয়ে দেয়। দুটি প্রভাবের কোনোটিই প্ল্যান তুলনায় দেখা যায় না।

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

বোর্ড আসলে আপনার কোথায় খরচ করায়

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

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

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

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

সাইফার বদলানোর আগে মাপুন

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

তুলনা করার সময় নিরাপত্তা নীতি অক্ষত রাখুন। দুর্বল সাইফার বা ওভারক্লক করা বোর্ডে পাওয়া পুরোনো ফলাফল বর্তমান স্থাপনার পরিকল্পনা নয়।

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

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

সম্পর্কিত নিবন্ধ