مشاركة عبر

استكشاف مشكلات الأداء العامة وإصلاحها باستخدام Azure Front Door

  • مقالة

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

التحقق من وجود مشاكل معروفة

قبل البدء، تحقق من وجود أي مشاكل معروفة على:

  • النظام الأساسي ل Azure Front Door.
  • موفرو خدمة الإنترنت (ISPs) في المسار.
  • قدرة العميل الطالب على الاتصال واسترداد البيانات.

السيناريو 1: التحقيق في الأصل

إذا كان أحد خوادم الأصل بطيئا، فإن الطلب الأول لكائن عبر Azure Front Door يكون بطيئا. علاوة على ذلك، إذا لم يتم تخزين المحتوى مؤقتا في نقطة حضور Azure Front Door (POP)، تتم إعادة توجيه الطلبات إلى الأصل. الخدمة من الأصل يلغي فائدة قرب POP والتسليم المحلي للعميل الطالب ويعتمد بدلا من ذلك على أداء الأصل.

السيناريو 1: معلومات البيئة المطلوبة

  • اسم نقطة نهاية Azure Front Door
    • اسم مضيف نقطة النهاية
    • مجال مخصص لنقطة النهاية (إن أمكن)
    • اسم المضيف الأصل
  • عنوان URL الكامل للملف المتأثر

السيناريو 1: خطوات استكشاف الأخطاء وإصلاحها

  1. تحقق من عناوين الاستجابة من الطلب المتأثر.

    للتحقق من رؤوس الاستجابة، استخدم الأمثلة التالية curl في Bash. يمكنك أيضا استخدام أدوات المطور في المستعرض عن طريق تحديد المفتاح F12. حدد علامة التبويب Networking، وحدد الملف ذي الصلة ليتم التحقيق فيه، ثم حدد علامة التبويب Headers. إذا كان الملف مفقودا، أعد تحميل الصفحة باستخدام أدوات المطور المفتوحة.

    يجب أن تحتوي الاستجابة الأولية على x-cache رأس بقيمة TCP_MISS أو CONFIG_NOCACHE . يقوم Azure Front Door POP بإعادة توجيه الطلبات بهذه القيمة إلى الأصل. يرسل الأصل حركة مرور الإرجاع على نفس المسار إلى العميل الطالب.

    فيما يلي مثال يوضح TCP_MISS:

    $ curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:02:09 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
x-fd-int-roxy-purgeid: 0
x-cache: TCP_MISS
accept-ranges: bytes

    فيما يلي مثال يوضح TCP_HIT:

    curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:04:38 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
x-fd-int-roxy-purgeid: 0
x-cache: TCP_HIT
x-cache-info: L1_T2
accept-ranges: bytes

  2. استمر في الطلب مقابل نقطة النهاية حتى يحتوي العنوان على x-cache TCP_HIT قيمة.

    إذا رأيت CONFIG_NOCACHEفي البداية ، فلن يتم تمكين التخزين المؤقت في تكوين المسار. في هذه الحالة، لن ترى TCP_HIT.

  3. إذا تم حل مشكلة الأداء، فإن المشكلة كانت تستند إلى سرعة الأصل وليس على أداء Azure Front Door. يحتاج المالك إلى معالجة إعدادات ذاكرة التخزين المؤقت ل Azure Front Door أو الأصل لتحسين الأداء.

    إذا استمرت المشكلة، فقد يكون المصدر هو العميل الذي يطلب المحتوى أو خدمة Azure Front Door. انتقل إلى السيناريو 2 لتحديد المصدر.

السيناريو 2: عميل واحد أو موقع واحد (على سبيل المثال، ISP) بطيء

يمكن أن يكون عميل أو موقع واحد بطيئا إذا كان هناك مسار شبكة غير صحيح بين العميل الطالب وAzure Front Door POP. يجب استبعاد أي مسار سيئ لأنه يؤثر على المسافة إلى POP، والذي يزيل ميزة التقارب ل Azure Front Door POP.

قد يكون زمن الانتقال العالي أو النطاق الترددي المنخفض نتيجة لمشكلة ISP، إذا كنت تستخدم شبكة خاصة ظاهرية (VPN) أو كنت جزءا من شبكة شركة موزعة. يمكن لشبكة الشركة تشغيل جميع حركة المرور من خلال نقطة مركزية بعيدة.

السيناريو 2: معلومات البيئة المطلوبة

  • اسم نقطة نهاية Azure Front Door
    • اسم مضيف نقطة النهاية
    • مجال مخصص لنقطة النهاية (إن أمكن)
    • اسم المضيف الأصل
  • عنوان URL الكامل للملف المتأثر
  • طلب معلومات العميل
    • طلب عنوان IP للعميل
    • طلب موقع العميل
    • طلب مسار العميل إلى بيئة Azure (عادة ما يتم تحديده باستخدام tracert أو pathping أو أداة مماثلة)

السيناريو 2: خطوات استكشاف الأخطاء وإصلاحها

  1. للتحقق من المسار إلى POP، استخدم pathping أو أداة مشابهة ل 500 حزمة للتحقق من مسار الشبكة.

    يحتوي المسار على 250 استعلارا كحد أقصى. للاختبار إلى 500، قم بتشغيل الاستعلام التالي مرتين:

    pathping /q 250 <Full URL of Affected File>

  2. تحديد ما إذا كانت نسبة استخدام الشبكة تأخذ مسارا من شأنه أن يضيف وقتا أو يسافر إلى منطقة بعيدة.

    ابحث عن رموز IP أو المدينة أو المنطقة التي لا تتخذ مسارا معقولا استنادا إلى جغرافيتك (على سبيل المثال، يتم توجيه حركة المرور في أوروبا إلى الولايات المتحدة) أو التي تحتوي على عدد كبير من القفزات.

  3. لاستبعد طلب إعدادات العميل، اختبر من عميل طلب مختلف في نفس المنطقة.

  4. إذا قمت بتحديد قفزات إضافية أو مناطق بعيدة، فإن المشكلة هي وصول العميل إلى Azure Front Door POP وليس مع خدمة Azure Front Door نفسها. يحتاج موفر الاتصال أو VPN إلى معالجة القفزات بين نقاط النهاية.

    إذا لم تحدد قفزات إضافية أو مناطق بعيدة ويتم تقديم المحتوى من ذاكرة التخزين المؤقت (x-cache: TCP_HIT)، فإن المشكلة هي في خدمة Azure Front Door. قد تحتاج إلى إنشاء طلب دعم. قم بتضمين مرجع إلى مقالة استكشاف الأخطاء وإصلاحها هذه والخطوات التي اتخذتها.

إشعار

عند تقديم المحتوى من الأصل (x-cache: TCP_MISS)، راجع السيناريو 1 سابقا في هذه المقالة.

السيناريو 3: يتم تحميل موقع ويب ببطء

في بعض السيناريوهات، لا توجد مشكلة في ملف واحد ولكن أداء صفحة ويب كاملة (Azure Front Door proxied) غير مرضي. تظهر أداة أداء صفحة الويب أداء ضعيفا للموقع مقارنة بصفحة ويب خارج Azure Front Door.

غالبا ما تتكون صفحة الويب من العديد من الملفات. يستفيد موقع الويب من Azure Front Door فقط إذا كان Azure Front Door يخدم كل ملف على صفحة ويب. يجب تكوين Azure Front Door لزيادة الفائدة إلى أقصى حد.

تأمل المثال التالي:

  • أصل: origin.contoso.com
  • المجال المخصص ل Azure Front Door: contoso.com
  • الصفحة التي تحاول تحميلها: https://contoso.com

عند تحميل الصفحة، يستدعي الملف الأولي في الدليل "/" ملفات أخرى، والتي تنشئ الصفحة. هذه الملفات هي الصور وJavaScript والملفات النصية والمزيد. إذا لم يتم استدعاء هذه الملفات عبر اسم مضيف Azure Front Door (contoso.com)، فإن الصفحة لا تستخدم Azure Front Door. لذلك، إذا كان أحد الملفات التي يطلبها موقع الويب هو http://www.images.fabrikam.com/businessimage.jpg، فإن الملف لا يستفيد من استخدام Azure Front Door. بدلا من ذلك، يطلب المستعرض على العميل الطالب الملف مباشرة من images.fabrikam.com الخادم.

رسم تخطيطي لملفات متعددة ومصدرة بشكل مختلف لموقع ويب مفرد وكيفية تأثير هذا التكوين على أداء Azure Front Door.

السيناريو 3: معلومات البيئة المطلوبة

  • اسم نقطة نهاية Azure Front Door
    • اسم مضيف نقطة النهاية
    • مجال مخصص لنقطة النهاية (إن أمكن)
    • اسم المضيف الأصل
    • الموقع الجغرافي للأصل
  • عنوان URL الكامل لصفحة الويب المتأثرة
  • الأداة والمقياس الذي يقاس الأداء

السيناريو 3: استكشاف الأخطاء وإصلاحها

  1. راجع المقياس الذي يظهر الأداء الأبطأ.

    هام

    لا يمكن ل Microsoft تمييز ما يتم قياسه بأدوات لا تملكها.

  2. افتح صفحة ويب Azure Front Door في مستعرض، ثم افتح أدوات المطور عن طريق تحديد المفتاح F12.

    يمكنك استخدام أدوات المطور في المستعرض الخاص بك لتحديد مصدر الملفات التي يتم تقديمها. لعرض عنوان URL للطلب في أدوات المطور، حدد علامة التبويب Networking ، وحدد الملف الذي تحقق فيه، ثم حدد General. إذا كان الملف مفقودا، أعد تحميل الصفحة باستخدام أدوات المطور المفتوحة.

  3. لاحظ مصدر الملفات أو عنوان URL للطلب.

  4. تحديد الملفات التي تستخدم اسم مضيف Azure Front Door والملفات غير الموجودة.

    في المثال السابق، ستكون https://www.contoso.com/productimage1.jpgالصورة المستضافة في Azure Front Door هي . صورة غير مستضافة في Azure Front Door ستكون http://www.images.fabrikam.com/businessimage.jpg.

  5. اختبر أداء الملف الذي يقدمه Azure Front Door وأصله وصفحة ويب الاختبار (إن أمكن).

    إذا تم تقديم صفحة ويب الأصل أو الاختبار من منطقة جغرافية أقرب إلى الأداة التي تقوم باختبار الأداء، فقد تحتاج إلى استخدام أداة أو طلب عميل في منطقة أخرى لفحص ميزة التقارب ل Azure Front Door POP.

    هام

    لن تستفيد أي ملفات يتم تقديمها من خارج اسم مضيف Azure Front Door منه. قد تحتاج إلى إعادة تصميم صفحة الويب للقيام بذلك.

    إذا كان من المفترض تخزين الملفات مؤقتا، فتأكد من اختبار الملفات التي تحتوي على عنوان الاستجابة x-cache: TCP_HIT.

  6. اتخاذ إجراء بناء على البيانات التي تم جمعها:

    • إذا أظهرت البيانات المجمعة أنه يتم إصدار الملفات من خوادم خارج اسم مضيف Azure Front Door، فإن Azure Front Door يعمل كما هو متوقع.

      قد يتطلب تحميل مواقع الويب ببطء تغييرا في تصميم صفحة الويب. للمساعدة في تحسين موقع الويب الخاص بك لاستخدام Azure Front Door، اتصل بفريق تصميم موقع الويب الخاص بك أو مع موفري حلول Microsoft.

      إشعار

      قد تستغرق مشكلة تحميل مواقع الويب ببطء وقتا للمراجعة، بناء على تعقيد تصميم موقع الويب وتعليماته المتعلقة بالاتصال بالملفات.

    • إذا أظهرت البيانات المجمعة أن أداء تحميل الملفات أفضل في Azure Front Door مقارنة بموقع الأصل أو الاختبار، فإن Azure Front Door يعمل كما هو متوقع. قد يكون مصدر المشكلة هو طلبات العميل الفردية. في هذه الحالة، راجع السيناريو 1 سابقا في هذه المقالة.

    • إذا أظهرت البيانات المجمعة أن الأداء ليس أفضل في Azure Front Door، فمن المحتمل أن تحتاج إلى تقديم طلب دعم لمزيد من التحقيق. قم بتضمين مرجع إلى مقالة استكشاف الأخطاء وإصلاحها هذه والخطوات التي اتخذتها.