fix content/post/web-server-percentiles.md

config.toml

@@ -1,4 +1,4 @@
-baseurl = "https://ctrlok.com"
+baseurl = "https://ctrlok.com/"
 languageCode = "ru-RU"
 title = "Блог Всеволода Полякова."
 disqusShortname = "adminyou"

content/post/web-server-percentiles.md

@@ -12,7 +12,7 @@ tags:
 
 ## Среднее значение и медиана.
 
-**Среднее значение** - это достаточно интересная метрика и при правильном использовании она может сказать нам много чего интересного. К сожалению, большинство людей используют её не к месту и хотят странного.
+**Среднее значение** - это достаточно интересная метрика и при правильном использовании она может сказать нам много чего полезного. К сожалению, большинство людей используют её не к месту и хотят странного.
 
 Среднее получить достаточно просто: надо взять все значения за период, сложить и поделить на их количество. Для нормальных данных всё просто и работает достаточно неплохо:
 
@@ -21,7 +21,7 @@ tags:
 ![](/images/mean-1.png)
 
 
-Тогда если среднее время повысится до 0.4, то мы увидим изменение среднего до 0.4, но то ли это изменение, которое мы хотим увидеть? Проблема в том, что мы увидим изменение и в том случае, если к нам придёт пользователь с медленным интернетом. Или два. И не обязательно с медленным интернетом, есть множество разных вещей, которые могут не зависеть от нашего сервера, но зависеть исключительно от пользователя. И это повысит среднее время ответа до, например, 1 секунды, не влияя на реальное положение дел.
+Тогда если каждый реквест начнёт исполнятся за 0.4 секунды, то мы увидим изменение среднего до 0.4. Проблема в том, что мы увидим изменение и в том случае, если к нам придёт пользователь с медленным интернетом. Или два. И не обязательно с медленным интернетом, есть множество разных вещей, которые могут не зависеть от нашего сервера, но зависеть исключительно от пользователя. И это повысит среднее время ответа до, например, 1 секунды, не влияя на реальное положение дел.
 
 ![](/images/mean-2.png)
 
@@ -33,9 +33,9 @@ tags:
 
 ![](/images/mediana-3.png)
 
-Если мы попробуем проанализировать, что такое медиана, то поймём — это максимальное время, за которое может загружаться страница как минимум у половины пользователей. То есть у одной половины пользователей страница будет загружаться гарантированно быстрее 0.3, а у другой половины пользователей - гарантированно медленнее.
+Если мы попробуем проанализировать, что такое медиана, то поймём — это максимальное время, за которое может загружаться страница как минимум у половины пользователей. То есть у одной половины страница будет загружаться гарантированно быстрее 0.3, а у другой половины - гарантированно медленнее.
 
-Но половина пользователей – это не совсем то количество, которое мы обычно покрываем SLA. Ну по крайней мере в моей компании. Ведь если ты скажешь бизнесу: "Мы гарантируем, что время загрузки страницы будет меньше 0.3 секунды как минимум у половины пользователей", то сразу получишь в лоб вопрос об оставшейся половине.
+Но половина пользователей – это не совсем то количество, которое мы обычно покрываем SLA. Ну по крайней мере в моей компании. Ведь если ты скажешь бизнесу: "Мы гарантируем, что время загрузки страницы будет меньше 0.3 секунды как минимум у 50% юзеров", то сразу получишь в лоб вопрос об оставшейся половине.
 
 Соответственно, для получения адекватной метрики стоит узнать, для какого процента пользователей мы хотим гарантировать время загрузки страницы, и потом вычислить это значение.
 
@@ -44,23 +44,23 @@ tags:
 
 Для нахождения перцентилей можно использовать разные средства, но если вы хотите получить метрики в приложения, то отличным выбором будет использовать [какой-то](https://github.com/github/brubeck) . [из](https://github.com/armon/statsite.git) .  [вариантов](https://github.com/vimeo/statsdaemon) . [statsd](https://github.com/etsy/statsd). В любом случае можно сохранять данные в какую-то БД и считать уже оттуда.
 
-Отбрасывая _аномальные_ метрики, мы можем вычислить как максимальное время, за которое какой-то процент пользователей гарантированно получит страницу, так и среднее значение, за которое этот же процент пользователей получает страницу. Стоит обратить внимание на то, что само по себе среднее значение всегда похоже на среднюю температуру по больнице и пусть и отображает среднее время ответа, но не передаёт представление о динамике. Так средняя температура может быть равна 35.5 градусам, если учитывать морг, и 40.1, если учитывать только реанимацию.
+Отбрасывая _аномальные_ метрики, мы можем вычислить как максимальное время, за которое какой-то процент пользователей гарантированно получит ответ, так и среднее значение, за которое этот же процент юзеров получает страницу. Стоит обратить внимание на то, что само по себе среднее значение всегда похоже на среднюю температуру по больнице и пусть и отображает среднее время ответа, но не передаёт представление о динамике. Так средняя температура может быть равна 35.5 градусам, если учитывать морг, и 40.1, если учитывать только реанимацию.
 
 Например, у нас есть два периода времени, 99 процентов реквестов для которых выглядят примерно так:
 
 ![](/images/perc-5.png)
 
 Соответственно, среднее время загрузки страницы для 99 процентов пользователей в обоих случаях будет 0.3с, в то время как половина пользователей из второго периода будут получать страницу намного дольше. И самое плохое - что мы никак это не увидим, если будем просто смотреть на среднее значение.
 
-Поэтому если вы всё-таки хотите смотреть на среднее значение, то на него стоит смотреть только в паре с [среднеквадратичным отклонением](https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%BA%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5), которое более-менее неплохо показывает расброс значений в выборке. Оно интерпретируется достаточно просто - чем выше значение отклонения, тем больше разброс значений. Зная среднеквадратичное отклонение, мы можем предположить, какой процент пользователей попадёт в радиус среднее значение (на графике **0**) ± среднеквадратичное отклонение (на графике **σ**)
+Поэтому если вы всё-таки хотите смотреть на среднее значение, то на него стоит смотреть только в паре с [среднеквадратичным отклонением](https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%BA%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5), которое более-менее неплохо показывает расброс значений в выборке. Оно интерпретируется достаточно просто - чем выше значение отклонения, тем больше разброс значений. Зная среднеквадратичное отклонение, мы можем предположить, какой процент пользователей попадёт в диапазое _среднее значение (на графике **0**) ± среднеквадратичное отклонение (на графике **σ**)_
 
 
 ![](https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Standard_deviation_diagram_%28decimal_comma%29.svg/400px-Standard_deviation_diagram_%28decimal_comma%29.svg.png)
 
 
 ## Осторожно с перцентилями
 
-Перцентили - достаточно удобный инструмент, и мы можем много чего сказать, вглядываясь в графики. Но стоит обратить внимание на то, что большинство TSDB агрегируют данные, а перцентили как-то очень плохо подходят для агрегации и для точных значений должны быть пересчитаны.
+Перцентили - достаточно удобный инструмент, и мы можем много чего сказать, вглядываясь в графики. Но стоит обратить внимание на то, что большинство TSDB постагрегируют данные, а перцентили как-то очень плохо подходят для постагрегации и для точных значений должны быть пересчитаны.
 
 
 Например, если в один период агрегации к нам пришло 100 запросов, для 99 процентов которых характерно время загрузки 0.3 секунды, и мы высчитали 99 перцентиль равным 0.3 секунды, а в следующий период к нам пришло два запроса, для которых 99-й перцентиль будет равен 10 секунд, то среднее значение после агрегации будет равно 5.1 секунды, в то время как если пересчитать перцентиль сразу для всех значений, то он будет равен 0.3
@@ -70,7 +70,7 @@ tags:
 
 _красным выделено среднее значение, а синим перцентиль для двух периодов_
 
-Поэтому перцентили надо хранить неагрегированными.
+Поэтому перцентили надо хранить как есть без постагрегаций или хранить время запросов и заново считать перцентили на большие диапазоны.
 
 Один из вариантов, как получать более-менeе точные значения и одновременно с этим иметь возможность постагрегации, - сразу писать количество запросов, которые укладываются в определённый интервал.
 
@@ -90,4 +90,4 @@ _красным выделено среднее значение, а синим
 
 В любом случае для любых расчётов важно знать, как и что у вас может работать. Ни в коем случае не стоит пытаться одной метрикой покрыть весь сайт, так как у вас там наверняка много разного контента, который работает по разным законам. И если, например, у вас на каждой странице отдаётся 100 статических файлов, а один запрос динамический, то вероятнее всего этот динамический запрос будет отфильтровываться в 99-м перцентиле и оказывать мало влияния на восприятие любых других графиков.
 
-Таким образом, желательно каждый важный для бизнеса запрос покрывать своими метриками и смотреть исключительно на эти метрики, потому как именно это время показывает, сколько пользователь ждёт до итоговой загрузки страницы.  
+Таким образом, желательно каждый важный для бизнеса запрос покрывать своими метриками и смотреть исключительно на эти метрики, потому как именно это время показывает,и  сколько пользователь ждёт до итоговой загрузки страницы.