في مشكلات الشبكات لا تكفي عبارة «الاتصال بطيء» لاختيار حل موثوق. يناقش هذا الدليل السؤال: كيف تكتشف أن بطء الموقع من DNS لا من الاستضافة؟ تجربة قياس منظمة ويقدّم طريقة تفصيلية للفصل بين الوقائع والافتراضات مع اختبارات يمكن تكرارها بأمان على شبكاتك أو بإذن أصحابها.
ما الذي تعنيه عبارة «الموقع بطيء»؟
عندما يضغط المستخدم على رابط، لا تبدأ العملية بطلب صفحة HTML مباشرة في كل الأحوال. قد يحتاج الجهاز أولًا إلى حل اسم النطاق عبر DNS، ثم إنشاء اتصال ومصافحة TLS، ثم إرسال الطلب وانتظار أول بايت وتحميل الموارد وعرضها. إذا كان اسم النطاق محفوظًا في ذاكرة التخزين المؤقت فلن يعكس الطلب التالي زمن حل جديد. لذلك لا يصح تحميل الاستضافة مسؤولية زمن حل أسماء مرتفع، ولا اتهام DNS إذا كان الخادم هو الذي ينتظر عدة ثوانٍ قبل أول بايت. الحل هو توزيع الزمن على مراحله داخل اختبار مضبوط.
اختبار الطلب البارد والدافئ
قارن تجربة أولى باسم غير مخزن مؤقتًا أو عبر أداة تدعم فصل زمن حل DNS عن زمن الاتصال، بتجربة لاحقة من الجهاز نفسه. حافظ على نفس الشبكة والنطاق والمسار وتوقيت الفحص قدر الإمكان. استخدم أداة تعرض DNS lookup و connection و TLS و TTFB والمدة الإجمالية، وسجل النتائج عبر عدة طلبات. لا تعتمد على وقت الصفحة كاملًا لأنه يشمل الصور و JavaScript وتخطيط العرض. إذا انخفض التأخير بوضوح بعد أول طلب فهناك احتمال أن التخزين المؤقت للأسماء أثر في النتيجة، لكن يمكن أن تكون عوامل أخرى مثل إعادة استخدام الاتصال وذاكرة التطبيق؛ لذلك عزل المتغيرات ضروري.
المقارنة بين محللات DNS
عند السماح بذلك وبدون تجاوز سياسات الشبكة، يمكن تجربة محلل DNS مختلف لمعرفة هل يتغير زمن الإجابة أو اتساقها، مع مراعاة أن اختيار عنوان CDN قد يختلف حسب المحلل والموقع الجغرافي. لا يكفي أن يكون المحلل أسرع بالميلي ثانية في استعلام واحد، إذا قاد إلى خادم CDN أبعد أو كانت له استجابات غير مستقرة. افحص أيضًا سجل A و AAAA و CNAME وتواريخ انتهاء TTL وتوافقها مع البنية المستضافة. عطل DNS قد يتجسد في فقد حل الاسم أو تأخره، لكن خطأ في العنوان النهائي قد يبدو للوهلة الأولى مثل تعطل الاستضافة.
كيف تختبر أداء الخادم بشكل مستقل؟
استخدم استدعاءً إلى عنوان الخدمة المناسب مع تثبيت اسم المضيف في الطلب عندما يكون ذلك آمنًا ومصرحًا به، لتمييز أثر DNS عن استجابة التطبيق دون تعطيل تحقق TLS. إذا كانت هذه المقارنة تتحسن فقط عند تجاوز حل الاسم، يصبح DNS مرشحًا قويًا، لكن ينبغي مراجعة الجدار الناري والشبكة أيضًا. وإذا بقي TTFB مرتفعًا في الحالتين فراجع سجلات التطبيق وقاعدة البيانات والتخزين المؤقت الخلفي وحمل المعالج. تجنب الحل السهل بتغيير DNS لكل مستخدمي الموقع قبل جمع بيانات من أكثر من شبكة؛ قد تعالج عرضًا على جهاز واحد وتترك الأصل.
لوحة متابعة بسيطة
قس الوسيط والمئين 95 لزمن حل DNS، وإنشاء الاتصال، و TLS، وأول بايت، والوقت الكامل. سجل عنوان الوجهة المختار وموقع الاختبار ووقت حدوثه ونوع الشبكة، مع فصل الاختبارات الباردة عن الدافئة. أضف نسبة الأخطاء وأكواد HTTP لتمييز انقطاع الخدمة عن مجرد البطء. ثم قارِن القياسات قبل أي تعديل وبعده خلال ظروف متشابهة، وراجع DNS TTL وسجلات المشغل وسجلات التطبيق. عند وجود فرق زمني ثابت يتكرر عبر الشبكات يمكن الاستنتاج بدرجة أعلى، أما تجربة واحدة ناجحة فليست سببًا لإعلان انتهاء المشكلة.
جدول التشخيص السريع
هذه احتمالات أولية لا تكفي للتشخيص دون تسجيل وقياس
| DNS مرتفع وحده | حل أسماء | افحص المحلل و TTL |
| TTFB مرتفع | تطبيق أو قاعدة بيانات | راجع الخادم |
| TLS مرتفع | مصافحة أو مسار | افحص الاتصال |
| الوقت الكامل مرتفع فقط | موارد واجهة | راجع الصور و JS |
خطة الفحص خطوة بخطوة
- افصل زمن DNS عن TCP و TLS و TTFB
- اختبر استعلامًا غير مخزن ثم طلبًا دافئًا
- قارن أكثر من محلل عند السماح
- اختبر عنوان الخدمة بثبات اسم المضيف
- كرر القياس عبر شبكات مختلفة
- راقب المئين 95 بعد الإصلاح
مراجع تقنية
للتفاصيل التقنية انظر إلى المواصفات والمصادر الأساسية: https://www.rfc-editor.org/rfc/rfc9110 ، https://www.cloudflare.com/learning/dns/what-is-dns/. وهذه المراجع تشرح سلوك البروتوكول ولا تثبت بالضرورة أن حالة شبكة بعينها ناتجة عن هذا السبب.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…