امتیاز Apdex
شاخص استاندارد رضایت از تأخیر بک‌اند، بین ۰ تا ۱، بر اساس تعداد درخواست‌های راضی، قابل‌تحمل و ناامیدکننده با آستانه‌ی ثابت 500ms.
Apdex (Application Performance Index) یک شاخص استاندارد صنعتی است که تأخیر را در یک عدد بین ۰٫۰۰ و ۱٫۰۰ خلاصه می‌کند. برخلاف صدک‌ها، نشان می‌دهد چه سهمی از کاربران واقعاً از زمان پاسخ راضی بوده‌اند، نه فقط این‌که کندترین درخواست‌ها چقدر کند بوده‌اند. ابرووا تریس این امتیاز را روی همه‌ی performance spanهای بازه‌ی زمانی انتخاب‌شده حساب می‌کند.
Apdex مدت درخواست‌ها را می‌سنجد و مکمل Web Vitals است (که رندر فرانت‌اند را می‌سنجد). برای تصویر کامل از تجربه‌ی کاربر هر دو را کنار هم ببینید.
نحوه‌ی محاسبه#
هر span نسبت به یک تأخیر هدف T (T = 500ms) در یکی از این دسته‌ها قرار می‌گیرد:
| دسته | بازه | وزن | معنی |
|---|---|---|---|
| راضی (Satisfied) | duration ≤ T (≤500ms) | 1.0 | کاربر پاسخ فوری گرفته است |
| قابل‌تحمل (Tolerating) | T < duration ≤ 4T (500ms-2s) | 0.5 | کند اما قابل‌استفاده |
| ناامید (Frustrated) | duration > 4T (>2s) | 0.0 | کاربر احتمالاً رها کرده یا دوباره تلاش کرده است |
سپس امتیاز این‌طور حساب می‌شود:
Apdex = (satisfied + tolerating × 0.5) / total
بازه‌های امتیاز (راهنما)#
در سطح صنعتی. کاربران تأخیر را به‌سختی حس می‌کنند
سالم. بیشتر تیم‌ها این بازه را حداقل هدف خود می‌گذارند
اصطکاک قابل‌مشاهده. تأخیر درخواست‌های کند باید بهتر شود
سهم قابل‌توجهی از درخواست‌ها کاربران را ناامید می‌کند؛ همین حالا بررسی کنید
چرا Apdex (و نه فقط p95)؟#
صدک‌ها به این سؤال جواب می‌دهند که «کندترین درخواست‌ها چقدر کندند؟» و Apdex به این‌که «چند کاربر تجربه‌ی بدی داشته‌اند؟». دو مثال:
- سرویس A: p95 = 1.8s اما p50 = 50ms. Apdex ≈ 0.93. بیشتر کاربران راضی‌اند؛ فقط تعدادی درخواست کند وجود دارد.
- سرویس B: p95 = 1.8s و p50 = 1.7s. Apdex ≈ 0.51. نیمی از کاربران ناامیدند.
p95 یکسان، اما واقعیت کاربر کاملاً متفاوت. Apdex مورد دوم را فوراً نشان می‌دهد.
خواندن امتیاز#
Apdex از همان فیلترهای بازه‌ی زمانی، پلتفرم، محیط و release پیروی می‌کند که بقیه‌ی صفحه‌ی ابرووا تریس ← Performance دارد. کنار امتیاز، تعداد درخواست‌های راضی، قابل‌تحمل و ناامید پشت آن را هم می‌بینید. اگر در بازه‌ی انتخاب‌شده هیچ spanی نباشد، امتیازی هم نیست.
تغییر آستانه#
T روی 500ms ثابت است، چون با SLA استاندارد وب برای «حس فوری بودن» هم‌خوان است. برای هر پروژه قابل‌تنظیم نیست. اگر کار شما واقعاً کندتر است (مثلاً inference یادگیری ماشین یا transcode ویدیو)، امتیاز بدبینانه به نظر می‌رسد؛ در این حالت روی روند امتیاز تمرکز کنید، نه مقدار مطلق آن.
بهترین روش‌ها#
حتی اگر T=500ms با SLA شما جور نباشد، روند امتیاز معنادار است؛ Apdex نزولی یعنی تجربه‌ی کاربر بدتر می‌شود
Apdex بالا با نرخ خطای بالا یعنی شکست‌های سریع. Apdex پایین با نرخ خطای پایین یعنی موفقیت‌های کند. هر دو به شکل متفاوتی به تجربه‌ی کاربر آسیب می‌زنند
رفتن Apdex از ۰٫۹۴ به ۰٫۸۵ کوچک‌تر از دو برابر شدن p95 به نظر می‌رسد، اما همان درد را برای کاربر نشان می‌دهد. برای هشدار، در «ابرووا تریس ← هشدارها» یک قانون هشدار برای تأخیر p95 بسازید
Apdex کلی ۰٫۹۲ برای کل سایت می‌تواند یک endpoint گیرکرده روی ۰٫۴۰ را پنهان کند. کارت عملیات در صفحه‌ی عملکرد p95 هر عملیات را برای بررسی دقیق‌تر نشان می‌دهد