تنزيلك سريع، فلماذا تبدو كل نقرة بطيئة؟

إن تنزيل ملف كبير بسرعة ثم إيجاد كل نقرة بطيئة ليس تناقضًا. تحدد السعة كم يمكن أن ينتقل في الثانية؛ ويحدد زمن الرحلة ذهابًا وإيابًا كم يستغرق التبادل قبل أن يحدث أي شيء مفيد. وتحسين الأول لا يفعل شيئًا للثاني، والثاني هو ما يلاحظه الشخص أثناء الكتابة أو النقر أو التحدث. قِس الشكوى لا الاتصال.

ملف سريع، نقرة بطيئة: رقمان مختلفان

يحافظ النقل بالجملة على بقاء البيانات في الحركة باستمرار، لذا يمكنه الإبلاغ عن معدل سليم حتى عندما ينتظر كل طلب على حدة. كما تفتح العديد من الاختبارات عدة اتصالات في وقت واحد، مما يرفع الرقم الإجمالي بينما يظل طلب واحد بطيئًا. والنتيجتان متوافقتان، واقتباس الرقم الأعلى لمستخدم يشكو من التأخر هو كيف تُفقد الثقة.

تحميل الصفحة سلسلة من التبادلات الصغيرة: تحليل الاسم، وإعداد الاتصال، وطلب، واستجابة، ثم طلبات تابعة. تدفع كل خطوة زمن الرحلة مرة أخرى، لذا يبدو المسار ذو التأخير العالي بطيئًا حتى عندما تكون لديه سعة وفيرة.

يضيف النفق رحلته ومعالجته الخاصة، والمسار يهم أكثر من التسمية على الخريطة. قد يكون لمخرجين في البلد نفسه مساران مختلفان جدًا إلى وجهة واحدة. وفارق عشرين ميلي ثانية كافٍ لتغيير إحساس الصفحة، رغم أنه بالكاد يحرك رقم معدل النقل. لهذا ينبغي أن يتبع اختيار المخرج عينة زمن استجابة بدلًا من أيقونة علم.

قِس الشكوى، لا الاتصال

اختر القياس الذي يطابق الجملة التي قالها المستخدم. التنزيل البطيء يحتاج إلى معدل مستمر في الاتجاه الصحيح؛ والمكالمة المتقطعة تحتاج إلى إحصاءات ذلك التطبيق نفسه؛ والصفحة التي تبدأ ببطء تحتاج إلى أزمنة تحليل الاسم والإعداد.

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 أثناء النقل ثم تعافت بعده، فقد أعدت إنتاج انتفاخ المخزن المؤقت بدلًا من اكتشاف عطل في التوجيه. والإصلاح عادةً إعداد لإدارة قائمة الانتظار، أو معدل خلفية أقل، أو نقل النقل الكبير بعيدًا عن المسار التفاعلي.

غالبًا ما يساعد تقليل حركة الخلفية الاختيارية أكثر من تغيير بلد المخرج. وهو أيضًا أرخص وقابل للعكس ويمكن اختباره في دقيقة. جدول الرفع الكبير خارج ساعات العمل إذا لم تكن قائمة الانتظار قابلة للإدارة، وحدد معدله إذا كان لا بد أن يعمل أثناء النهار. إعداد إدارة قائمة الانتظار هو الإصلاح الأفضل عندما يدعمه الموجه.

غيّر شيئًا واحدًا وقارن المثل بالمثل

بالنسبة لتأخير الخمول المرتفع، قارن المخارج مع تثبيت الوجهة، ثم قارن المسارات لأفضل مرشح. وبالنسبة لمعدل النقل المنخفض المستقر، انظر بدلًا من ذلك إلى السعة وحمل الخادم ومعالجة العميل، لأن تلك حدود مختلفة.

اكتب ما قسته، مقابل أي وجهة، وفي أي وقت، وبأي إعدادات. المقارنة بلا هذه الحقائق الأربع لا يمكن تكرارها، وسيبدأ الشخص التالي من الصفر.

ثم طابق الأداة مع الادعاء في التذكرة. "الإنترنت بطيء" ليس قياسًا؛ "استغرق أول بايت 900 مللي ثانية إلى هذا المضيف بينما كان معدل النقل جيدًا" قياس، ويشير مباشرة إلى التأخير لا إلى السعة.