Комментарии 9
Они позволяют понять, как система работает бóльшую часть времени, в отличие от усреднения значений, которое сильно подвержено влиянию выбросов. Если 9 из 10 запросов выполняются за 1 секунду, а один за 10 секунд, то среднее будет 1,9 секунды, а 50-перцентиль — 1 секунда. Это лишь один пример того, что среднее значение не подходит для мониторинга.
Маленькая ремарка — типов "среднего" больше одного, есть и такие, которые НЕ подвержены сильному влиянию выбросов. Дело не во влиянии выбросов, а в том, что среднее (любое) в данном случае попросту не несет никакого реального смысла. Когда мы задаемся вопросом "А что именно мы хотим измерить", становится ясно, что в случае типа "как система реагирует на большинство запросов" нужен именно перцентиль, а не среднее.
Народ спрашивает: а какое количество вставок/сек в итоге вывозит summary коллектор?
Зависит от вставляемых данных (порядок, разброс значений). Последняя итерация делала в среднем 3млн вставок в секунду для рандомных данных от 0 до 100.
Игорь, спасибо за статью! Только непонятно, почему не считать перцентили прямо в проме?
Кажется, что для расчета перцентилей можно использовать поиск k-ой порядковой статистики. Это такая модификация quicksort, где мы отбрасываем одну из «половин» массива.
Тогда время работы будет O(n) вместо O(n log n) на сортировку.
Тогда время работы будет O(n) вместо O(n log n) на сортировку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расчет перцентилей для мониторинга высоконагруженных систем