Изначальная проблема которую я пытаюсь решить: переезжаем на новый сервис. Хотим проверить, что новый сервис держит пиковую нагрузку, которую держал старый.
В данный момент я пытаюсь измерить пиковую нагрузку, что бы описать её. Метрика нужна что бы
1. передать её в команду поддержки API, возможно они сразу скажут что она слишком высока и сервис не выдержит
2. попытатся повторить её (например jmeter-ом)
Есть логи в которых логируется окончание запроса и его длительность.
Пытаюсь вычислить rpm (requests per minute), но не получается. Чем меньше интервал я беру в регионе спайка, тем выше получаются значения RPM.
Приведу пример, чтоб было понятнее. Пусть у нас есть 1 запрос в течении часа. Какая нагрузка? RPM = 1/60 = 0.0167
Ок, начинаем проверять интервалы размером в 1ms. Все будут с RPM=0 кроме одного, у которого RPM=1*60*1000 = 60000.
Как выбрать интервал? Может нужна какая-то другая метрика?
SJA>Приведу пример, чтоб было понятнее. Пусть у нас есть 1 запрос в течении часа. Какая нагрузка? RPM = 1/60 = 0.0167
Усредненно, да. НО если ты хочешь РПМ то брать интервалы в час это мм, странно.
SJA>Ок, начинаем проверять интервалы размером в 1ms. Все будут с RPM=0 кроме одного, у которого RPM=1*60*1000 = 60000.
Тут тоже надо усреднять а не экстаполировать, в минуте 60000 миллисекунд соотв твой пиковый RPM=1
SJA>Как выбрать интервал? Может нужна какая-то другая метрика?
Для RPM брать меньше минуты смысла нет. Точнее можно по каждой ms брать интервал [t-30000..t+30000) считать для него RPM и потом выбрать максимальный, но это уже перебор как по мне.
Здравствуйте, GarryIV, Вы писали:
SJA>>Приведу пример, чтоб было понятнее. Пусть у нас есть 1 запрос в течении часа. Какая нагрузка? RPM = 1/60 = 0.0167 GIV>Усредненно, да. НО если ты хочешь РПМ то брать интервалы в час это мм, странно.
час и милисекунда были как пример неадекватно больших/маленьких интервалов. Адекватный по видимому лежит внутри, но как его вычислить?
SJA>>Ок, начинаем проверять интервалы размером в 1ms. Все будут с RPM=0 кроме одного, у которого RPM=1*60*1000 = 60000. GIV>Тут тоже надо усреднять а не экстаполировать, в минуте 60000 миллисекунд соотв твой пиковый RPM=1
А почему именно "в минуте"? Потому что это RPM ? Это как бы и имеет смысл и не имеет...
Пиковая нагрузка измеряется в RPM но значит ли это что именно 1m интервал нас интересует.
А если мерять в RPS, значит интересует 1 сек интервал?
Получается RPM = 1 и RPS = 1 ерунда какая-то.
SJA>>Как выбрать интервал? Может нужна какая-то другая метрика? GIV>Для RPM брать меньше минуты смысла нет. Точнее можно по каждой ms брать интервал [t-30000..t+30000) считать для него RPM и потом выбрать максимальный, но это уже перебор как по мне.
Мне кажется это ещё зависит от времени выполнения запроса и от количества ещё может.
Если запрос занимает например 1 ns, то интервал можно и секунду брать. В течении секунды могут быть и пики и ямы.
В моём слкучае это десятки милисекунд. И минутный интервал выглядит адекватно, но... вот расчёты
Здравствуйте, Sergey J. A., Вы писали:
SJA>Изначальная проблема которую я пытаюсь решить: переезжаем на новый сервис. Хотим проверить, что новый сервис держит пиковую нагрузку, которую держал старый. SJA>В данный момент я пытаюсь измерить пиковую нагрузку, что бы описать её. Метрика нужна что бы SJA>... SJA>Как выбрать интервал? Может нужна какая-то другая метрика?
Во время пиковых нагрузок обычно проседает время ответа сервиса, вплоть до таймаутов. Чаще всего во время пиковых нагрузок ошибки — таймауты. У вас почти наверняка есть таймауты на обращение к сервису.
Вот именно таймауты и будут интересны — если сервис начинает таймаутить, то он начинает захлёбываться: с высокой долей вероятности будут ретраи, если не у клиента, который непосредственно таймаут словил, то у того кто к этому клиенту обращался. Это порождает лавинообразное нарастание нагрузки. В общем интересно, сколько за время таймаута может прилететь реквестов.
При большой нагрузке таймауты почти неизбежны. Практика показала, что процент таймаутов для оценки состояния сервиса — весьма полезная метрика. Смысл в том, что мониторинг ошибок не показывает производительности сервиса, этого недостаточно — таймауты нужно смотреть отдельно. Точно так же недостаточно среднего времени ответа сервиса: глядя на такой график непонятно, много это или мало. 95-й квантиль более показателен в этом плане: в случае проблем с производительностью вы скорее всего будете расследовать не средние случаи, а проблемные.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sergey J. A., Вы писали:
SJA> Как выбрать интервал? Может нужна какая-то другая метрика?
Если предполагается, что время ответа сервиса менее секунды (а это большинство веб-сервисов и, судя по "В моём случае это десятки миллисекунд", это твой случай), то обычно нагрузку измеряют в rps (запросов в секунду).
SJA> Есть логи в которых логируется окончание запроса и его длительность.
* Грубо можно посчитать пиковый rps взяв число запросов из логов за сутки из пропорции 1 млн запросов = 100 rps.
* Если есть логи, то можешь округлить время окончания запроса до секунды и посчитать максимум после группировки по времени.
* Если совсем хочется "упороться", то можешь вычитать из времени окончания запроса длительность и группировать по точкам старта, но значения не должны сильно разойтись с предыдущим способом подсчета, так что я бы не стал так заморачиваться.
Логи желательно взять за неделю или более, т.к. в разные дни будут разные пики (обычно они хорошо коррелируют с днем недели).
SJA> Приведу пример, чтоб было понятнее. Пусть у нас есть 1 запрос в течении часа. Какая нагрузка?
Для времени обработки запроса за десятки миллисекунд это нагрузка 0 ("ноль rps") — т.е. настолько маленькая, что для сервиса на фоне потока запросов от других клиентов будет неразличима и ей можно пренебречь.
SJA>>>Приведу пример, чтоб было понятнее. Пусть у нас есть 1 запрос в течении часа. SJA>Получается RPM = 1 и RPS = 1 ерунда какая-то.
Ну да куча датапоинтов по 0 и 1 шт с 1 хоть в фемтосекунду считай. Что не так?
С 1 запросом в час то еще извращение запросы в минуту считать.
Если у тебя на реальных данных РПМ и РПС рассчитанные таким способом одинаковые (или близкие) то это только говорит о том, что пики в нагрузке короткие, меньше секунды и говорить о РПМ бессмысленно.
ЗЫЖ Можно мелкие датапоинты усреднять по более крупным интервалам (считать за секунду как показано выше, суммировать датапоинты за минуту и делить на количество датапоинтов, то есть на 60) но для твоих целей я бы это не стал использовать. Для задач типа оптимизации расходов да, для расчета максимальной нагрузки нет.
В любом случае экстраполировать максимумы глупо — ведет к дикому росту метрики при уменьшении интервала что ты и наблюдаешь.
Здравствуйте, GarryIV, Вы писали:
GIV>В любом случае экстраполировать максимумы глупо — ведет к дикому росту метрики при уменьшении интервала что ты и наблюдаешь.
Так в этом и вопрос — как выбрать этот интервал? Думаю есть для этого какие-то математические подходы...
Коллега на работе уверен, что если нужно получить RPM то и мерять надо за минуту. Но я с этим не согласен, для меня RPM — это скорость, её можно и на 30 секундном интервале померять и на 15. Коллега уверен, что RPM это не скорость. ХЗ
Здравствуйте, Anton Batenev, Вы писали:
AB>Если предполагается, что время ответа сервиса менее секунды (а это большинство веб-сервисов и, судя по "В моём случае это десятки миллисекунд", это твой случай), то обычно нагрузку измеряют в rps (запросов в секунду).
Но ведь это одно и тоже? Т.е. 1rps = 60rpm, и в чём измерять — вопрос удобства. Как скорость в км/ч или в м/с.
Хотя вот мой коллега говорит, что нельзя их приводить таким образом.
А твоё мнение?
AB>Для времени обработки запроса за десятки миллисекунд это нагрузка 0 ("ноль rps") — т.е. настолько маленькая, что для сервиса на фоне потока запросов от других клиентов будет неразличима и ей можно пренебречь.
Хочется какую-то формулу или эвристику, где можно по времени запроса получить размер интервала.
GIV>>В любом случае экстраполировать максимумы глупо — ведет к дикому росту метрики при уменьшении интервала что ты и наблюдаешь. SJA>Так в этом и вопрос — как выбрать этот интервал? Думаю есть для этого какие-то математические подходы... SJA>Коллега на работе уверен, что если нужно получить RPM то и мерять надо за минуту. Но я с этим не согласен, для меня RPM — это скорость, её можно и на 30 секундном интервале померять и на 15. Коллега уверен, что RPM это не скорость. ХЗ
Вобщем то твой коллега прав, для целей оценки нагрузки самое оно. Простой select max(cnt) from (select minute, count(*) cnt from requests group by minute) даст тебе адекватную оценку.
Я не очень понимаю чего ты хочешь добиться? Нагрузка сильно прыгает в течении минуты и ты хочешь быть уверен что АПИ справится с всплесками? Перед тем как спорить о природе РПМ и в математику лезть неплохо было бы понимать что ты от нее хочешь, математике пофиг — может 1000 лет выдать и 1 фемтосекунду.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Но ведь это одно и тоже? Т.е. 1rps = 60rpm, и в чём измерять — вопрос удобства. Как скорость в км/ч или в м/с.
если говорить о мгновенной скорости то пофиг, да
только тебе не она нужна
Здравствуйте, Anton Batenev, Вы писали:
AB>* Грубо можно посчитать пиковый rps взяв число запросов из логов за сутки из пропорции 1 млн запросов = 100 rps.
Все-таки речь о 10 rps (на порядок меньше), ибо 1000000/(24*3600)~ 11 .
Здравствуйте, GarryIV, Вы писали:
GIV>>>В любом случае экстраполировать максимумы глупо — ведет к дикому росту метрики при уменьшении интервала что ты и наблюдаешь. SJA>>Так в этом и вопрос — как выбрать этот интервал? Думаю есть для этого какие-то математические подходы... SJA>>Коллега на работе уверен, что если нужно получить RPM то и мерять надо за минуту. Но я с этим не согласен, для меня RPM — это скорость, её можно и на 30 секундном интервале померять и на 15. Коллега уверен, что RPM это не скорость. ХЗ
GIV>Вобщем то твой коллега прав, для целей оценки нагрузки самое оно. Простой select max(cnt) from (select minute, count(*) cnt from requests group by minute) даст тебе адекватную оценку.
GIV>Я не очень понимаю чего ты хочешь добиться?
Хочу понять как правильно описывать пиковую нагрузку что бы:
1. можно было спросить "мы ожидаем пиковую нагрузку X, может ваш сервис её выдерживать?"
2. можно было написать в User Story "протестировать сервис S с нагрузкой полтора X" и уйти в отпуск. и что бы данных в описании было достаточно для выполнения теста.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Хочу понять как правильно описывать пиковую нагрузку что бы уйти в отпуск.
Тогда надо описывать,
* какие исходные данные
* какие запросы (параметры)
* профиль нагрузки (стабильная, стабильная с кратковременными пиками и тд)
Здравствуйте, Sharov, Вы писали:
S> AB>* Грубо можно посчитать пиковый rps взяв число запросов из логов за сутки из пропорции 1 млн запросов = 100 rps. S> Все-таки речь о 10 rps (на порядок меньше), ибо 1000000/(24*3600)~ 11 .
Ты взял среднюю, а в течении дня нагрузка от людей неравномерна (в 4-6 утра минимум, в какие-то часы наибольшей нагрузки может легко быть x10).
Например, приложение "расписание школьных занятий" испытывает ЧНН в воскресенье вечером с сентября по июнь (потому что за выходные все всё забыли и делают запросы перед началом учебного дня), а приложение погоды имеет ЧНН в ПТ утром с апреля-мая по сентябрь-октабрь, потому как в ПТ народ едет вечером на дачи / загород. Таких примеров можно привести множество в зависимости от специфики приложения.
Здравствуйте, Sergey J. A., Вы писали:
SJA> Но ведь это одно и тоже? Т.е. 1rps = 60rpm, и в чём измерять — вопрос удобства. Как скорость в км/ч или в м/с. SJA> Хотя вот мой коллега говорит, что нельзя их приводить таким образом. SJA> А твоё мнение?
Нет, в общем случае это разные единицы измерения из за малых масштабов неравномерности событий. Поскольку считается, что нормальный ответ веб-сервиса находится в пределах 300 ms, то на одном ядре CPU мы можем выполнить 3 rps. Дальше тупо умножаем на количество ядер.
Есть отличная книжка под названием "Проектируем время Психология восприятия времени в программном обеспечении", там эта тема немного раскрыта.
SJA> AB>Для времени обработки запроса за десятки миллисекунд это нагрузка 0 ("ноль rps") — т.е. настолько маленькая, что для сервиса на фоне потока запросов от других клиентов будет неразличима и ей можно пренебречь. SJA> Хочется какую-то формулу или эвристику, где можно по времени запроса получить размер интервала.
Тут все зависит от того, что у тебя за веб-сервис. Среднестатистический веб-сервис в вакууме отвечает за 300 ms => ты измеряешь нагрузку в requests per second (см. отсылку к книге выше). Если стандартный ответ твоего веб-сервиса в пределах единиц ms (такое бывает например в HFT), то у тебя requests per 100/10/1 ms (но это сильно специфичные случаи и ты бы о них знал). Так что наиболее оптимальная единица для тебя — это rps.
Здравствуйте, Anton Batenev, Вы писали:
AB>Есть отличная книжка под названием "Проектируем время Психология восприятия времени в программном обеспечении", там эта тема немного раскрыта.
Советуете? С технической тз имеет смысл читать, практическая польза может быть, или это некие общие
рассуждения психологико-философского характера?
Здравствуйте, Sharov, Вы писали:
S> Советуете? С технической тз имеет смысл читать, практическая польза может быть, или это некие общие S> рассуждения психологико-философского характера?
Стоит почитать, если занимаешься UX или нагруженными web-приложениями. Книжка всего на 200 страниц, читается за один вечер. Я бы сказал, что она технико-философская (опирается на различные исследования, оперирует некоторыми числами, но при этом она все же про людей).
Здравствуйте, Anton Batenev, Вы писали:
AB>Есть отличная книжка под названием "Проектируем время Психология восприятия времени в программном обеспечении", там эта тема немного раскрыта.
Почитал по диагонали, но что-то ничего по своей теме не нашёл. Мож пропустил...
AB>Если стандартный ответ твоего веб-сервиса в пределах единиц ms (такое бывает например в HFT), то у тебя requests per 100/10/1 ms (но это сильно специфичные случаи и ты бы о них знал).
Вот меня это как-то удивляет. Звучит как, если машина, тогда меряем в км/ч, а если человек бежит, тогда измеряем в м/с. Главное не путать.
