شرح · اثنان
التنزيل الذي يمضي على أتم وجه هو الحالة السهلة، وكل برنامج يتدبّرها باقتدار. أما الفروق المثيرة للاهتمام فتظهر حين ينقص جزء من المنشور، وذلك يحدث أكثر بكثير مما توحي به الحالة النظيفة. هذا ما يجري فعلًا، ولماذا يكلّف كل هذا الوقت.
شكل المشكلة
منشور Usenet ليس ملفًا واحدًا. إنه آلاف المقالات الصغيرة، كل منها مخزَّن على نحو مستقل في خواديم كل مزود، وملف NZB الذي تنزّله قائمةٌ بأسمائها. والإصدار بحجم 6.5 GB نحو 9,000 منها.
تضيع المقالات لأسباب عادية. يحتفظ بها المزودون مدة استبقاء ثابتة ثم يحذفونها. وبعض المزودين لم يستلموا مقالة بعينها من الأصل، لأن الانتشار بين الخواديم ناقص. وأحيانًا يكون الرفع غير مكتمل وقت النشر، فلا يوجد جزء منه في أي مكان قط. ومهما كان السبب فالأثر واحد: يطلب برنامجك مقالة، فيأتي الجواب رفضًا لا بيانات.
وهذا شائع بما يكفي ليحسب له من ينشرون على Usenet حسابًا. فمع كل إصدار تقريبًا تأتي بيانات تماثل، عادةً ملفات PAR2، أي معلومات زائدة إضافية محسوبة من الأصل. فإن نقص شيء من المحتوى استطاع التماثل إعادة بنائه، ما دام لديك ما يكفي منه. ويحمل المنشور النموذجي نحو 10% تماثلًا، فيمكن للمنشور أن يفقد جزءًا لا بأس به من نفسه ويظل قابلًا للاسترجاع تمامًا.
فالمنشور التالف ليس عادةً تنزيلًا معطوبًا. إنه تنزيل يقتضي شيئًا من الحساب قبل أن يكتمل. والسؤال الوحيد هو كم يستغرق البرنامج ليدرك ذلك، وهنا بالضبط تتفاوت البرامج بمقدار الضعف أو أكثر.
الجزء المكلف
حين لا تكون المقالة عند خادوم يعيد رفضًا، فيجرّب البرنامج عندئذ الخادوم التالي في قائمتك. وهذا هو الصواب، لأن المزود الثاني كثيرًا ما تكون عنده. ويظهر الثمن حين لا تكون عند أحد.
في تلك الحالة يمشي البرنامج على قائمة مزوديك كلها، خادومًا خادومًا، ويُرفض من كل واحد منهم قبل أن يستطيع أن يخلص إلى أن المقالة زالت حقًا. والمشي متسلسل، والرفض أبطأ مما يفترض الناس. قِسناه مباشرةً، على خط ساكن، دون أي محتوى يتحرك:
| المزود | زمن الرد على طلب عادي | زمن رفض مقالة ناقصة |
|---|---|---|
| المزود A | 77.5 ms | 78.8 ms |
| المزود B | 10.5 ms | 454 ms |
| المزود C | 10.8 ms | 871 ms |
| المزود D | 9.9 ms | 1,227 ms |
| المزود E | 10.6 ms | 2,239 ms |
يبرز أمران. أولهما أن التباين هائل: يكلّف الرفض ما بين 79 ms و2.2 ثانية تبعًا للمزود المجيب، فارق يقارب ثلاثين ضعفًا. وثانيهما أن مزودًا يرفض في نحو الزمن الذي يستغرقه السؤال، بينما يستغرق آخر أكثر من مئتي ضعف زمن استجابته المعتاد ليقول لا. وهذا ليس تأخر شبكة، بل عمل يجري عندهم، والسؤال بجولات أقل لا يكاد ينفع.
اجمع ذلك: مشية كاملة عبر خمسة مزودين، لمقالة واحدة لم تعد موجودة، تكلّف نحو 5 ثوانٍ. ثم تأمل أن المنشور التالف فيه مقالات كثيرة كهذه، وأن برنامجًا يعالجها بالتتابع يدفع ذلك الثمن مرارًا بينما يظل اتصالك عاطلًا. التنزيل ليس بطيئًا لأن البيانات تصل ببطء. لقد توقفت عن الوصول أصلًا، والبرنامج ينتظر أن يُقال له ما لديه من المعلومات ما يكفي لاستنتاجه.
الحل
البصيرة ليست في تسريع الرفض، فنحن لا نتحكم بالمزودين. بل في ملاحظة اللحظة التي لم يعد فيها للجواب أثر.
في أي لحظة أثناء التنزيل يعرف البرنامج أمرين: كم قطعة ما زالت مفقودة، وكم من بيانات التماثل بحوزته. فإن كان ما بيده من تماثل يكفي لإعادة بناء كل ما بقي معلقًا، فإن الجواب عن سؤال «هل عند أحد هذه المقالة؟» لم يعد قادرًا على تغيير النتيجة. سواء أكان نعمًا بطيئة أم لا بطيئة، فالملف يُعاد بناؤه على أي حال. ومواصلة المشي لا تشتري شيئًا سوى التأخير.
لذا يكفّ الإصدار الحالي عن السؤال عند تلك النقطة ويمضي مباشرةً إلى الإصلاح. وإعادة البناء نفسها سريعة وكانت كذلك دائمًا: نحو 2.3 ثانية على منشور بحجم 6.5 GB، وذلك الرقم واحد في كل نسخة قِسناها. والوقت الموفَّر كله هو الانتظار الذي لم يعد يحدث.
| منشور 6.5 GB، 60 مقالة ناقصة | الزمن حتى ملف متحقَّق منه |
|---|---|
| انتظار رفض كل مزود | 23 s |
| التوقف ما إن يغطي التماثل الفجوة | 13 s |
| ومنه، حساب الإصلاح الفعلي | 2.3 s |
والتغيير نفسه لا يفعل شيئًا البتة على منشور سليم، وهو أوضح دليل على أنه يفعل ما نظن: فبلا مقالات ناقصة لا مشية تُختصر، وينهي الإصداران مهمة نظيفة بحجم 6.5 GB في 7 ثوانٍ متطابقة.
إنها مقايضة لا مكسب مجاني. فالإصلاح المبكر يعني الاحتفاظ ببيانات التماثل في الذاكرة بدل طرحها وجلب المزيد لاحقًا، فترتفع ذروة الذاكرة (RSS) على منشور شديد التلف من نحو 0.8 GB إلى نحو 1.3 GB، ونسحب من المزودين نحو 400 MB زيادة. أما على منشور سليم فالذاكرة على حالها عند 0.24 GB. ونرى أنها المقايضة الصحيحة لأكثر الناس، إذ لا تُنفق الذاكرة إلا في الحالة التي تشتري لك فيها عشر ثوانٍ، لكنها كلفة حقيقية ولها إعداد.
حُجبت أسماء المزودين في جدول الرفض عمدًا. فهذه الأرقام خاصية قياس واحد في مساء واحد من موضع واحد، والمزود الذي يفهرس على نحو مختلف، أو الذي صادفناه في ليلة سيئة، لا ينبغي أن يوسم بالبطء استنادًا إلى جولة واحدة. والذي يهم في الحجة هو الشكل: الرفض يتفاوت تفاوتًا هائلًا، والمجموع كبير بما يكفي ليهيمن على تنزيل تالف. أرقام كل مزود ومخرجات السبر الخام في سجلنا الداخلي، والأرقام من طرف إلى طرف التي تفسّرها في صفحة قياس الأداء.