ব্রাউজারে ৫.৫ MB Python runtime শিপিং করা একটি দল লক্ষ্য করল যে, সাম্প্রতিক একটি স্প্রিন্টের সময় লগ করা ত্রুটিগুলোর (errors) মধ্যে ৬৯% একটি মাত্র বিভ্রান্তিকর শিরোনামের অধীনে ছিল, এবং সেগুলোর মধ্যে ৮৯% আসলে ছিল নেটওয়ার্ক টাইমআউট (network timeouts)। এই ভুল রিপোর্টিং ডেভেলপারদের ভুল ডিবাগিং পথে পরিচালিত করেছিল এবং ব্যবহারকারীদের একটি বড় অংশকে নিঃশব্দ ডাউনলোড ব্যর্থতার (silent download failures) সম্মুখীন করেছিল—যেকোনো ওয়েব-অ্যাপ যা বড় অ্যাসেট (assets) বা ফাইল গুচ্ছ ব্যবহার করে, খুব শীঘ্রই এই সমস্যার সম্মুখীন হতে পারে।
ড্যাশবোর্ড বিভ্রান্ত করেছিল
এরর-ট্র্যাকিং সিস্টেমটি স্বয়ংক্রিয়ভাবে ঘটনাগুলোকে সেই কোড লোকেশন অনুযায়ী গ্রুপ করে যেখানে সেগুলো প্রথম দেখা দেয়। এর ফলে যে শিরোনামটি পাওয়া গিয়েছিল তা দেখে মনে হয়েছিল এটি রানটাইম লোডারের একটি সাধারণ বাগ (bug), তাই পুরো স্প্রিন্টটি এমন সব কোড পাথ (code paths) খুঁজতে ব্যয় করা হয়েছিল যেগুলোতে কখনও টাইমআউট ঘটেনি। যখন দলটি মূল মেটাডেটা (metadata) পরীক্ষা করল, তখন আসল চিত্রটি সামনে এল: বেশিরভাগ ব্যর্থতা আসলে কোনো বাগ ছিল না, বরং সেগুলো ছিল থমকে যাওয়া নেটওয়ার্ক কানেকশন যা টাইমআউট ঘটিয়েছিল।
মূল শিক্ষা: একটি এরর টাইটেল বা ত্রুটির শিরোনাম কেবল সুবিধার জন্য, এটি কোনো রোগনির্ণয় (diagnosis) নয়। শিরোনামটি আসলে কী নির্দেশ করছে তা যাচাই করতে নিয়মিত র (raw) ডেটা গভীরভাবে পরীক্ষা করুন।
ব্রাউজার কানেকশন API একটি প্লেসহোল্ডার প্রদান করেছিল
ধীরগতির ব্যবহারকারীদের ৫.৫ MB ডাউনলোড করতে বাধ্য করা এড়াতে, ডেভেলপাররা ব্রাউজারের Network Information API (navigator.connection) ব্যবহার করেছিলেন। APIটি প্রতিটি নতুন ভিজিটর বা প্রথমবার আসা ব্যবহারকারীর জন্য ১.৭ Mbps ব্যান্ডউইথ (bandwidth) স্থিরভাবে রিপোর্ট করছিল।
নতুন ব্যবহারকারীর জন্য কোনো ঐতিহাসিক ডেটা না থাকলে ব্রাউজারগুলো একটি ডিফল্ট (default) মান প্রদান করে। সেই ডিফল্ট মানটি কেবল একটি ইঙ্গিত মাত্র, এটি কোনো নিশ্চিত গতি নয়। যখন প্রতিটি নতুন সেশনের জন্য একই প্লেসহোল্ডার দেখা যায়, তখন এটি সংকেত দেয় যে API-টি সেই অডিয়েন্স বা ব্যবহারকারীদের জন্য এখনও সঠিকভাবে ক্যালিব্রেট (calibrate) করা হয়নি।
মূল শিক্ষা: যে নেটওয়ার্ক সিগন্যাল কখনও পরিবর্তিত হয় না, সেটিকে একটি ফলব্যাক (fallback) হিসেবে বিবেচনা করুন, নিশ্চিত মেট্রিক (metric) হিসেবে নয়।
ওয়ান-অফ স্ন্যাপশট (One-off snapshots) নির্ভরযোগ্য নয়
অনির্ভরযোগ্য ব্যান্ডউইথ ইঙ্গিতটি বাদ দেওয়ার পর, দলটি অন্য একটি সিগন্যাল ব্যবহার করতে শুরু করল যা তাদের টেস্ট সুইটে (test suite) কার্যকর বলে মনে হয়েছিল। একবার টেস্ট রান সফল হলেও, তিনবার পরীক্ষা করার পর প্রতিবারই ব্যর্থতা দেখা দিল। নেটওয়ার্কের গতি ক্রমাগত ওঠানামা করে। কোডটি কেবল একটি মাত্র স্ন্যাপশট নিয়েছিল, একটি স্থায়ী সিদ্ধান্ত নিয়েছিল এবং তার পরের মুহূর্তেই কানেকশন পরিবর্তন হয়ে গেলেও সেটি চালিয়ে গিয়েছিল।
মূল শিক্ষা: পরিবর্তনশীল কোনো বিষয়ের ওপর ভিত্তি করে একটি মাত্র রিডিং বা পাঠের মাধ্যমে স্থায়ী সিদ্ধান্ত নেবেন না। একবার পোলিং (polling) করার পরিবর্তে চেঞ্জ ইভেন্টগুলোর (change events) সাবস্ক্রাইব করুন।
দলটি যেসব ব্যবহারিক সমাধান প্রয়োগ করেছে
- কানেকশন পরিবর্তনের সাবস্ক্রাইব করা।
navigator.connectionএকবার পড়ার পরিবর্তে, কোডটি এখনchangeইভেন্টের জন্য অপেক্ষা করে এবং ডাউনলোডের সময় ব্যান্ডউইথ কমলে বা বাড়লে সেই অনুযায়ী ব্যবস্থা নেয়। - একটি “no-progress” ওয়াচডগ যোগ করা। একটি টাইমার এমন যেকোনো রিকোয়েস্ট বাতিল করে দেয় যা অল্প সময়ের মধ্যে কোনো অগ্রগতি করতে পারে না, ফলে ব্রাউজারটি পুনরায় চেষ্টা করার বা ফলব্যাক করার সুযোগ পায়।
- ডাউনলোড চলাকালীন CDN পরিবর্তন করা বন্ধ করা। ধীরগতির লিঙ্কে বড় ফাইলের সোর্স পরিবর্তন করলে ট্রান্সফারটি আবার শূন্য থেকে শুরু হয়, ফলে ইতিমধ্যে প্রাপ্ত ডেটা বা বাইটগুলো নষ্ট হয়। ডাউনলোডটি এখন পুরো সময় জুড়ে প্রাথমিকভাবে নির্বাচিত CDN-এই সীমাবদ্ধ থাকে।
- ভারী ক্যাশিং (caching) কাজ স্থগিত রাখা। ক্যাশে প্রচুর পরিমাণে ডেটা লেখার কাজগুলো রানটাইম লোডিং শেষ না হওয়া পর্যন্ত স্থগিত রাখা হয়, যাতে ক্রিটিক্যাল পাথ (critical path) সংক্ষিপ্ত থাকে।
আপনার ড্যাশবোর্ড যদি অস্বাভাবিকভাবে নিখুঁত চিত্র দেখায়, তবে আরও গভীরভাবে অনুসন্ধান করুন। যদি কোনো নেটওয়ার্ক পরিমাপ কখনও পরিবর্তিত না হয়, তবে সেটিকে একটি প্লেসহোল্ডার হিসেবে বিবেচনা করুন। আর যদি একটি মাত্র স্ন্যাপশট একটি মাল্টি-মেগাবাইট ডাউনলোডের ভাগ্য নির্ধারণ করে, তবে আপনি একটি মরীচিকার ওপর বাজি ধরছেন। এই বাজিগুলো নিঃশব্দ ব্যর্থতা হিসেবে প্রকাশ পায় যা ব্যবহারকারীর আস্থা কমিয়ে দেয়—এমন কিছু যা পরে যতই চতুর কোড দিয়ে চেষ্টা করা হোক না কেন, পুরোপুরি মেরামত করা সম্ভব নয়।
