কম বিলম্বের প্রক্সিতেও ডাউনলোড ধীর হতে পারে কেন
সংযোগের বিলম্ব ও ডাউনলোডের থ্রুপুট প্রক্সি অনুরোধের আলাদা অংশ মাপে। কাজ অনুযায়ী সঠিক পরীক্ষা বেছে নিন।
যে প্রক্সি ছোট পৃষ্ঠা দ্রুত ফেরত দেয়, সেটি ফাইল ডাউনলোডে ধীরও হতে পারে। প্রথম অনুরোধ মূলত সংযোগ স্থাপন ও প্রতিক্রিয়ার বিলম্ব জানায়। বড় স্থানান্তরের ক্ষেত্রে পথটি একটানা কত ডেটা বহন করতে পারে, সেটিও গুরুত্বপূর্ণ।
কোন পরিমাপটি আপনার প্রশ্নের উত্তর দেয়?
| কাজ | প্রাসঙ্গিক পর্যবেক্ষণ |
|---|---|
| ছোট পৃষ্ঠা খোলা বা ছোট API অনুরোধ পাঠানো | সংযোগ স্থাপনসহ প্রতিক্রিয়া পেতে লাগা সময়। |
| ফাইল ডাউনলোড করা | উপযুক্ত পরীক্ষামূলক ফাইলে মোট স্থানান্তরিত বাইট ও গড় থ্রুপুট। |
| অনেক অনুরোধের মধ্যেও অ্যাপকে দ্রুত সাড়া দিতে রাখা | প্রত্যাশিত কাজের চাপে স্বাভাবিক প্রতিক্রিয়ার সময়, ব্যর্থতা এবং সংযোগের পুনর্ব্যবহার। |
ICMP ping আলাদা পরীক্ষা। প্রক্সি সেবা অনুপলব্ধ থাকলেও সার্ভার ping-এর উত্তর দিতে পারে, আবার প্রক্সি সচল থাকলেও ping বন্ধ থাকতে পারে। প্রক্সির ঠিকানায় যাওয়া-আসার সময়ে প্রক্সি থেকে আপনার গন্তব্যে সংযোগের সময়ও ধরা পড়ে না।
প্রকৃত স্থানান্তর মাপুন
নিজের নিয়ন্ত্রণে থাকা সার্ভারের ফাইল বা এ ধরনের পরীক্ষার জন্য নির্ধারিত ফাইল ব্যবহার করুন। এই উদাহরণ প্রতিক্রিয়ার বডি ফেলে দিয়ে স্থানান্তরের আকার, প্রতি সেকেন্ডে গড় বাইট এবং মোট সময় দেখায়:
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin
উদাহরণের প্রক্সি ও ফাইলের URL দুটিই বদলান। 404 পৃষ্ঠা বা প্রবেশাধিকার প্রত্যাখ্যানের প্রতিক্রিয়া দ্রুত এলেও তা বৈধ ডাউনলোড বেঞ্চমার্ক নয়। গতি তুলনার আগে স্ট্যাটাস, ফাইলের প্রত্যাশিত আকার ও বিষয়বস্তু যাচাই করুন।
গড় গতির ঘরটি প্রতি সেকেন্ডে বাইট হিসেবে দেখানো হয়। প্রতি সেকেন্ডে বিটে বিজ্ঞাপিত নেটওয়ার্ক প্যাকেজ ভিন্ন একক ব্যবহার করে। বাইট থেকে বিটে আনুমানিক রূপান্তরে আট দিয়ে গুণ করুন; পুরো তুলনায় একই একক রাখুন।
তুলনার শর্ত একই রাখুন
একই গন্তব্য, ফাইল, ক্লায়েন্ট নেটওয়ার্ক ও টাইমআউটের সেটিং ব্যবহার করুন। দ্রুততম চেষ্টাটি বেছে না নিয়ে কয়েকটি সীমিত নমুনা তুলনা করুন। আটকে থাকা স্থানান্তরের জন্য সংযোগ স্থাপন, মোট সময় ও কম গতির সীমা ভেবেচিন্তে বেছে নিন। ব্যর্থ অনুরোধও ফলাফলে রাখুন: যে প্রক্সি কখনো দ্রুত ডেটা পাঠায় কিন্তু প্রায়ই ব্যর্থ হয়, তা শেষ করতেই হবে এমন কাজের জন্য অনুপযুক্ত হতে পারে।
ক্যাশে থাকা ফাইল ও নতুন ডাউনলোড সেবার ভেতরে আলাদা পথে যেতে পারে। নতুন সংযোগ স্থাপনের পরের অনুরোধ ও পুরোনো সংযোগ পুনর্ব্যবহার করা অনুরোধের ক্ষেত্রেও তা হতে পারে। আপনার অ্যাপের কোন আচরণ দরকার তা ঠিক করে ধারাবাহিকভাবে সেটিই মাপুন।
কাজের ধরন অনুযায়ী বেছে নিন
ছোট API প্রতিক্রিয়ায় প্রথম বাইটের আগে অতিরিক্ত এক সেকেন্ড অপেক্ষা সর্বোচ্চ থ্রুপুটের চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে। বড় ডাউনলোডে দ্রুত হ্যান্ডশেকের পরে খুব ধীর বডি পাওয়া সুবিধাজনক সমঝোতা নয়। উভয় ক্ষেত্রেই আসলে যে গন্তব্য ব্যবহার করবেন সেটি পরীক্ষা করুন; প্রক্সির সব পথ বোঝাতে পারে এমন একটিমাত্র গতির স্কোর নেই।
ProxyHub প্রক্সি তালিকা প্রতিটি IP-এর জন্য স্বাধীন থ্রুপুটের পরিমাপ দেয় না। প্রোটোকল বা দেশ অনুযায়ী ফিল্টার গতির ক্রমতালিকা নয়।