Apdex (مؤشر أداء التطبيق): الدليل الفني الكامل والمعيار المتري

Apdex (مؤشر أداء التطبيق) هو معيار صناعي مفتوح تم تطويره بواسطة تحالف من شركات برمجيات المؤسسات لقياس مدى رضا المستخدم عن وقت استجابة تطبيقات الويب وخدمات تكنولوجيا المعلومات.

بدلاً من الاعتماد فقط على مقاييس وقت الاستجابة المتوسطة أو المئوية، تقوم Apdex بتحويل مقاييس زمن الاستجابة الفنية إلى درجة واحدة موحدة بين 0.0 (غير مقبول) و1.0 (ممتاز) والتي تعكس بشكل مباشر رضا المستخدم النهائي.

الإجابة-الملخص الأول

تعمل نتيجة Apdex على تحويل أوقات استجابة التطبيق إلى مقياس واحد موحد بين 0.00 و1.00 يقيس رضا المستخدم.يتم تصنيف الطلبات إلى راضية ($\le T$)، ومتسامحة ($> T \text{ و } \le 4T$)، ومحبطة ($> 4T$ أو أخطاء HTTP 5xx) استنادًا إلى وقت الاستجابة المستهدف $T$ (عادةً من 200 مللي ثانية إلى 500 مللي ثانية).الصيغة هي $\text {Apdex} _T = (\text {Satisfied} + (\text {Tolerating} / 2)) / \text{إجمالي العينات}$.تمثل درجة Apdex الأعلى من 0.94 أداءً ممتازًا، بينما تشير الدرجات الأقل من 0.70 إلى إحباط شديد لدى المستخدم يتطلب تحسينًا هندسيًا فوريًا.

كيف يتم حساب نقاط Apdex

يقوم حساب Apdex بتصنيف كل طلب مستخدم في واحدة من ثلاث مناطق أداء متميزة بناءً على حد هدف وقت الاستجابة المحدد $T$ (مثل $200\text {ms} $):

1. راضي: الطلبات ذات أوقات الاستجابة $\le T$.يتمتع المستخدمون بالاستجابة المثلى ويتابعون سير العمل دون تردد.
2. التسامح: الطلبات ذات أوقات الاستجابة $> T$ و$\le 4T$.يلاحظ المستخدمون تأخيرًا بسيطًا ولكن يمكنهم إكمال مهمتهم دون التخلي عن التطبيق.
3. محبط: الطلبات ذات أوقات الاستجابة $> 4T$ أو الطلبات التي تؤدي إلى خطأ HTTP (رمز الحالة 5xx).يواجه المستخدمون تباطؤًا غير مقبول أو انهيارًا تامًا في الخدمة.

يتم التعبير عن الصيغة الرياضية لدرجة Apdex على النحو التالي:

$$\text {Apdex} _T = \frac{\text{العدد المُرضي} + \frac{\text{عدد التسامح}}{2}}{\text{إجمالي العينات}}$$

عملت مثال رياضي

خذ بعين الاعتبار تطبيق SaaS الذي يتلقى 10000 طلب خلال نافذة مراقبة مدتها ساعة واحدة مع حد مستهدف $T = 200\text {ms} $:

• الطلبات التي تمت تلبيتها ($\le 200\text {ms} $): 8,500
• القبول للطلبات (200 دولار\نص {ms} < t \le 800\text {ms} $): 1,000
• الطلبات المحبطة ($> 800\text {ms} أخطاء $ أو 5xx): 500

يؤدي توصيل هذه القيم في صيغة Apdex إلى الحصول على ما يلي:

$$\text {Apdex} _ {200} = \frac{8500 + \frac {1000} {2}} {10000} = \frac{8500 + 500} {10000} = \frac{9000} {10000} = 0.90$$

تندرج درجة Apdex البالغة 0.90 ضمن فئة جيد، مما يشير إلى أنه على الرغم من أن معظم المستخدمين يستمتعون بتجربة سريعة، إلا أن 15% من الطلبات تواجه زمن استجابة أو أخطاء تتطلب التحسين.

مقياس تصنيف Apdex وفئات النتيجة

يحدد Apdex Alliance خمسة نطاقات تصنيف موحدة لترجمة الدرجات الرقمية إلى أهداف هندسية قابلة للتنفيذ:

اختيار عتبة الهدف الصحيحة $T$

يعد تحديد الحد المستهدف المناسب $T$ أمرًا بالغ الأهمية للحصول على درجات Apdex القابلة للتنفيذ.إذا تم تعيين $T$ على قيمة عالية جدًا (على سبيل المثال، $2000\text {ms} $)، فسيتم تصنيف الطلبات البطيئة بشكل خاطئ على أنها "مرضية".وعلى العكس من ذلك، إذا تم تعيين $T$ على مستوى منخفض للغاية (على سبيل المثال، $20\text {ms} $)، فإن زمن الوصول العادي للشبكة سوف يعاقب على نتيجة تطبيقك دون داع.

الحدود المستهدفة الموصى بها حسب نوع التطبيق:

• واجهات برمجة التطبيقات والخدمات الصغيرة: $T = 100\text {ms} - 200\text {ms} $
• تطبيقات الويب SaaS التفاعلية: $T = 200\text {ms} - 400\text {ms} $
• صفحات منتجات التجارة الإلكترونية: $T = 300\text {ms} - 500\text {ms} $
• منصات الوسائط والمحتوى الثقيلة: $T = 500\text {ms} - 1000\text {ms} $

لماذا يتفوق Apdex على متوسط ​​وقت الاستجابة؟

تشير أدوات المراقبة التقليدية في كثير من الأحيان إلى متوسط ​​أوقات الاستجابة.ومع ذلك، يمكن أن تكون المتوسطات مضللة للغاية للأسباب التالية:

1. انحراف خارجي: قد يؤدي عدد صغير من المهلات البالغة 30 ثانية إلى تضخيم متوسط ​​وقت الاستجابة لآلاف الطلبات السريعة التي تبلغ 50 مللي ثانية بشكل مصطنع، مما يؤدي إلى إنشاء إنذارات كاذبة.
2. التوزيعات الثنائية: عندما يخدم أحد التطبيقات الأصول الثابتة المخزنة مؤقتًا في 10 مللي ثانية واستعلامات قاعدة البيانات المعقدة غير المخزنة مؤقتًا في 2000 مللي ثانية، فإن متوسط ​​1005 مللي ثانية لا يمثل تجربة المستخدم بدقة.
3. التطبيع الذي يركز على المستخدم: تعمل Apdex على تطبيع مقاييس الاستجابة إلى درجة يمكن فهمها من 0 إلى 1 والتي يمكن لأصحاب المصلحة غير التقنيين ومديري المنتجات والمديرين التنفيذيين تتبعها بمرور الوقت دون الحاجة إلى خبرة عميقة في القياس عن بعد.
4. ترجيح الخطأ: يتعامل Apdex تلقائيًا مع أخطاء خادم HTTP 5xx ومهلات الشبكة باعتبارها طلبات محبطة، مما يلتقط حالات فشل التوفر مباشرةً داخل فهرس الأداء.

Apdex مقابل مؤشرات أداء الويب الأساسية (LCP وINP)

بينما تم تطوير Apdex في الأصل لأوقات الاستجابة من جانب الخادم وأدوات APM، فإن هندسة أداء الويب الحديثة تتطلب دمج Apdex مع مؤشرات الويب الأساسية من Google:

• Apdex: يقيس وقت استجابة خادم الواجهة الخلفية وزمن وصول معالجة واجهة برمجة التطبيقات عبر جميع طلبات HTTP.
• أكبر طلاء محتوى (LCP): يقيس سرعة التحميل المرئي للواجهة الأمامية عندما ينتهي عرض أكبر عنصر محتوى في إطار العرض الخاص بالمستخدم.
• التفاعل مع الرسم التالي (INP): يقيس استجابة واجهة المستخدم الأمامية أثناء تفاعلات المستخدم (النقرات والنقرات وضغطات المفاتيح).

من خلال تتبع Apdex لنقاط نهاية Go/Gin API للواجهة الخلفية لديك جنبًا إلى جنب مع LCP وINP لتطبيق Nuxt 4 للواجهة الأمامية، تحقق الفرق الهندسية رؤية شاملة عبر الأداء من جانب الخادم والعميل.

دمج Apdex في سير عمل المراقبة المستمرة

SimpleOps يتتبع تلقائيًا نتائج Apdex عبر جميع نقاط نهاية HTTP المسجلة، ومسارات تطبيقات الويب، وخدمات API الصغيرة.من خلال الجمع بين اختبار الاتصال الاصطناعي من أكثر من 15 موقع فحص عالمي مع القياس عن بعد للمستخدم الحقيقي، SimpleOps ينبه فريقك الهندسي عبر Slack أو Telegram أو Webhooks عندما تنخفض درجة Apdex لتطبيقك إلى ما دون عتبة SLO التي تم تكوينها.

من خلال مراقبة Apdex جنبًا إلى جنب مع وقت التشغيل الاصطناعي وCore Web Vitals، تكتسب فرق DevOps رؤية كاملة لكل من التوفر وجودة الأداء عبر مجموعات المستخدمين العالمية، مما يمنع توقف العملاء وحماية إيرادات الأعمال.