আপনার ডাউনলোড দ্রুত, তাহলে প্রতিটি ক্লিক ধীর কেন লাগে?

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

দ্রুত ফাইল, ধীর ক্লিক: দুই ভিন্ন সংখ্যা

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

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

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

সংযোগ নয়, অভিযোগ মাপুন

ব্যবহারকারী যে বাক্যটি বলেছেন তার সঙ্গে মেলে এমন পরিমাপ বেছে নিন। ধীর ডাউনলোডের জন্য সঠিক দিকে ধারাবাহিক হার দরকার; দেরিতে সাড়া দেওয়া কলে ওই অ্যাপ্লিকেশনের নিজের পরিসংখ্যান দরকার; ধীরে শুরু হওয়া পাতার জন্য নাম সমাধান ও সংযোগ স্থাপনের সময় দরকার।

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

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

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

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

লোডের মধ্যে বিলম্ব সারির সমস্যা

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

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

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

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

একটি জিনিস বদলান আর সমানের সঙ্গে সমান তুলনা করুন

বেশি নিষ্ক্রিয় বিলম্বের জন্য গন্তব্য স্থির রেখে এগ্রেস তুলনা করুন, তারপর সেরা প্রার্থীর জন্য রুট তুলনা করুন। কম স্থির থ্রুপুটের জন্য বরং ক্যাপাসিটি, সার্ভার লোড ও ক্লায়েন্ট প্রক্রিয়াকরণ দেখুন, কারণ ওগুলো ভিন্ন সীমা।

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

তারপর টিকিটের দাবির সঙ্গে যন্ত্রটি মিলিয়ে নিন। "ইন্টারনেট ধীর" কোনো পরিমাপ নয়; "এই হোস্টে প্রথম বাইটে 900 ms লাগল, অথচ থ্রুপুট ভালো ছিল" একটি পরিমাপ, এবং এটি ক্যাপাসিটির দিকে নয়, সরাসরি বিলম্বের দিকে ইশারা করে।