مشاركة عبر

ضبط الأداء للتطبيق الموزع

  • مقالة

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

السيناريوهات:

ما هو الأداء؟

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

حدد هدف مستوى الخدمة (SLO) الذي يحدد أهداف الأداء لكل حمل عمل. عادة ما تحقق هذا الهدف عن طريق تقسيم هدف الأداء إلى مجموعة من مؤشرات الأداء الرئيسية (KPIs)، مثل:

  • الكمون أو وقت الاستجابة لطلبات محددة
  • عدد الطلبات التي يتم إجراؤها في الثانية
  • معدل إنشاء النظام للاستثناءات.

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

قد يكون مثال SLO ل: "طلبات العميل لها استجابة في غضون 500 مللي ثانية @ P90، عند تحميل ما يصل إلى 25 K طلب/ثانية."

تحديات ضبط الأداء لنظام موزع

قد يكون من الصعب بشكل خاص تشخيص مشكلات الأداء في تطبيق موزع. بعض التحديات هي:

  • عادةً ما تتضمن العملية أو العملية التجارية الواحدة مكونات متعددة للنظام. قد يكون من الصعب الحصول على نظرة شاملة وشاملة لعملية واحدة.

  • يتم توزيع استهلاك الموارد عبر عقد متعددة. للحصول على عرض متسق، تحتاج إلى تجميع السجلات والقياسات في مكان واحد.

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

  • غالبا ما لا تتوسع أحمال العمل عبر الذاكرات الأساسية أو مؤشرات الترابط. من المهم فهم متطلبات أحمال العمل الخاصة بك والنظر في الأحجام المحسنة بشكل أفضل. توفر بعض الأحجام ذاكرات أساسية مقيدة وفرط قراءة معطلة لتحسين أحمال العمل الفردية الموجهة نحو الذاكرة الأساسية ولكل أحمال العمل المرخصة الأساسية.

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

أفضل الممارسات العامة

يعد ضبط الأداء فناً وعلماً، ولكن يمكن جعله أقرب إلى العلم من خلال اتباع نهج منهجي. فيما يلي مجموعة من أفضل الممارسات:

  • قم بتمكين التتبع عن بعد لجمع القياسات. صك التعليمة البرمجية الخاص بك. اتبع أفضل الممارسات للمراقبة. استخدم التتبع المترابط بحيث يمكنك عرض جميع الخطوات في العملية.

  • راقب النسب المئوية 90/95/99، وليس المتوسط ​​فقط. يمكن للمتوسط ​​إخفاء القيم المتطرفة. معدل أخذ العينات للقياسات مهم أيضاً. إذا كان معدل أخذ العينات منخفضاً جداً، فيمكنه إخفاء الارتفاعات أو القيم الخارجية التي قد تشير إلى وجود مشاكل.

  • هاجم ازدحاماً واحداً في كل مرة. كوّن فرضية واختبرها بتغيير متغير واحد في كل مرة. غالباً ما تكشف إزالة ازدحام واحد عن ازدحام آخر في المصدر أو في انتقال البيانات من الخادم.

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

  • ابحث عن أنماط الأداء المضادةالشائعة.

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

الخطوات التالية

اقرأ سيناريوهات ضبط الأداء