Два нагрузочных теста получили одинаковый Apdex при разном среднем времени ответа. Как интерпретировать сопоставимость их результатов?
Одинаковый Apdex не означает одинаковую производительность. Этот показатель переводит задержки в несколько пороговых категорий, поэтому разные распределения времени ответа могут дать один и тот же результат. Тесты можно считать сопоставимыми по доле удовлетворительных, терпимых и неудовлетворительных запросов, но нельзя делать вывод об одинаковой фактической задержке или одинаковом пользовательском опыте.
Apdex появился как прикладной способ связать техническую метрику времени ответа с восприятием качества обслуживания. Вместо анализа только среднего времени система классифицирует запросы относительно целевого порога и формирует нормированную оценку удовлетворённости.
Такой подход удобен для отчётности: технические результаты можно выразить одной шкалой от 0 до 1. Однако упрощение достигается ценой потери части информации о точном распределении задержек.
Apdex использует порог удовлетворительного времени T. В распространённой схеме запросы с задержкой не выше T считаются удовлетворительными, запросы между T и 4T — терпимыми, а запросы выше 4T — неудовлетворительными; конкретные границы должны быть явно заданы в методике теста.
Обычно оценка рассчитывается так: доля удовлетворительных запросов плюс половина доли терпимых. Поэтому, например, 100% терпимых запросов и сочетание 50% удовлетворительных с 50% неудовлетворительных могут дать одинаковый Apdex 0,5, хотя риски для пользователя различаются.
Если сравнивать только Apdex, можно не заметить, что в одном тесте задержки сгруппированы около границы категории, а в другом часть запросов имеет экстремально большие значения. Неверный вывод особенно опасен при выборе версии сервиса или проверке SLA: одинаковая итоговая оценка может скрывать разную тяжесть деградации.
Apdex — это пороговая агрегированная метрика, а не замена распределению задержек. Она отвечает на вопрос: какая часть операций укладывается в целевой уровень, какая ещё приемлема с ухудшением, а какая уже неприемлема.
При одинаковом Apdex сначала нужно сравнить составляющие: долю удовлетворительных, терпимых и неудовлетворительных запросов. Затем следует изучить объём операций, среднее и медианное время ответа, высокие перцентили, распределение по типам операций и динамику по временным окнам.
Главное ограничение — потеря детализации внутри категорий. Запросы с задержками 1,1T и 3,9T попадают в одну терпимую категорию, хотя нагрузка на пользователя и запас до границы неудовлетворительного результата у них различаются. Аналогично значения 4,1T и 40T могут иметь одинаковый вклад в Apdex.
Порог T нельзя выбирать произвольно после получения результатов. Его задают до теста на основании требований к конкретной операции, а для разных типов операций используют разные пороги или рассчитывают показатели раздельно. Иначе изменение порога может создать видимое улучшение без изменения поведения системы.
Практический вывод: Apdex подходит для компактного контроля качества и сравнения доли запросов в целевых классах, но должен дополняться перцентилями, абсолютными значениями задержки, ошибками и временными рядами. При одинаковом Apdex предпочтение нельзя обосновывать только этой метрикой.
Для двух версий сервиса задан порог T в одну секунду. В первой версии половина запросов выполняется за 0,5 секунды, а половина — за 5 секунд. Во второй все запросы выполняются примерно за 2 секунды. Обе версии могут получить одинаковый Apdex 0,5: в первом случае запросы разделились между удовлетворительными и неудовлетворительными, во втором все попали в терпимую категорию.
Рассматривались три варианта. Выбрать версию только по Apdex было бы быстро, но скрыло бы структуру задержек. Выбрать по среднему времени ответа — лучше для оценки общей длительности, но среднее не показывает, насколько много пользователей столкнулось с плохим хвостом. Ориентироваться только на p99 тоже недостаточно: он описывает край распределения, но не долю пользователей в каждой категории.
Было выбрано совместное решение: сравнить Apdex и его компоненты, p50 и p95, долю запросов выше 4T и графики по временным окнам. Если бизнес-критичны редкие, но очень долгие операции, версия с меньшим неудовлетворительным хвостом получает преимущество даже при одинаковом Apdex. Такой анализ сохраняет смысл пороговой метрики и не принимает её за полное описание производительности.
1. Может ли одинаковый Apdex означать одинаковое соблюдение SLA?
Нет, если SLA задан как отдельное требование, например «не менее 99% запросов должны завершаться не дольше двух секунд». Apdex использует собственные категории и веса, поэтому одинаковое его значение может быть получено при разной доле нарушений конкретного SLA. Соблюдение SLA проверяют непосредственно по его формулировке, а Apdex используют как дополнительный показатель.
2. Что изменится, если для двух операций выбрать один общий порог T?
Одинаковый порог может быть некорректен для операций с разной бизнес-ценностью и разной нормальной сложностью. Быстрый поиск и оформление заказа могут иметь разные приемлемые задержки, поэтому общий Apdex будет смешивать несопоставимые ожидания. Правильнее задавать пороги по типам операций или хотя бы рассчитывать Apdex раздельно, а затем агрегировать результаты с явно указанными весами.
3. Почему рост Apdex не всегда доказывает ускорение сервиса?
Apdex может вырасти из-за небольшого перемещения запросов через порог категории, даже если сами задержки внутри категорий почти не изменились. Например, переход части запросов с 1,01T на 0,99T улучшит классификацию, но не обязательно будет заметен пользователю. Поэтому рост Apdex нужно подтверждать изменениями распределения задержек, перцентилей, абсолютных значений и отсутствием ухудшения у отдельных критичных операций.