[object Object]

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, которое получает 10 000 запросов в течение часового окна мониторинга с целевым порогом $T = 200\text {ms} $:

• Выполненных запросов ($\le 200\text {ms} $): 8 500
• Допускаемые запросы ($200\text {ms} < t \le 800\text {ms} $): 1000
• Неудовлетворенные запросы ($> 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 определяет пять стандартизированных диапазонов рейтингов для перевода числовых оценок в практически осуществимые инженерные цели:

Выбор правильного целевого порога $T$

Выбор подходящего целевого порога $T$ имеет решающее значение для получения действенных показателей Apdex.Если значение $T$ слишком велико (например, $2000\text {ms} $), медленные запросы будут ошибочно отнесены к категории «Выполнено».И наоборот, если $T$ установлено слишком низко (например, $20\text {ms} $), обычная задержка в сети приведет к ненужному снижению оценки вашего приложения.

Рекомендуемые целевые пороговые значения по типам приложений:

• API и микросервисы: $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 с Core Web Vitals от Google:

• Apdex: измеряет время ответа внутреннего сервера и задержку обработки API для всех HTTP-запросов.
• Наибольшая отрисовка контента (LCP): измеряет скорость визуальной загрузки интерфейса, когда самый большой элемент контента завершает рендеринг в области просмотра пользователя.
• Взаимодействие с следующей отрисовкой (INP). Измеряет скорость реагирования пользовательского интерфейса во время взаимодействия с пользователем (щелчков, касаний и нажатий клавиш).

Отслеживая Apdex для ваших конечных точек серверного Go/Gin API наряду с LCP и INP для вашего внешнего приложения Nuxt 4, команды инженеров достигают сквозной прозрачности производительности как на стороне сервера, так и на стороне клиента.

Интеграция Apdex в рабочие процессы непрерывного мониторинга

SimpleOps автоматически отслеживает оценки Apdex для всех зарегистрированных конечных точек HTTP, маршрутов веб-приложений и микросервисов API.Сочетая синтетический зондовый пинг из более чем 15 глобальных точек проверки с телеметрией реальных пользователей, SimpleOps предупреждает вашу команду разработчиков через Slack, Telegram или Webhooks, когда показатель Apdex вашего приложения падает ниже настроенного порога SLO.

Контролируя Apdex наряду с синтетическим временем безотказной работы и основными веб-показателями, команды DevOps получают полную информацию о доступности и качестве производительности среди групп пользователей по всему миру, предотвращая отток клиентов и защищая доходы бизнеса.