Комментарии 11
Спасибо за статью, взял в закладки. Возникло 3 вопроса:
1) Что понимается под термином SLA ?
есть какие-то SLA
IMHO "SLA" это аббревиатура от стандартного термина в ITIL : "Service Level Agreement".
Может быть корректнее использовать термин "граничное условие" (thresholds) ?
2) Проводится ли статистическая обработка результатов?
3) А можно примеры из жизни ?
Добрый вечер! Давайте по порядку:
Под термином SLA в статье подразумеваются требования к системе, например, в моем случае это RPS X10 от RPS-са на продакшене
Не совсем понял вопрос, можете, пожалуйста, подробнее описать, что имеется ввиду?
В статье приведен пример из жизни, автоматизация НТ и применение самого сервиса аналитики, данный процесс работает сейчас на реальном проекте, просто я не вдавался в продуктовые/командные подробности. Если вы подразумевали это, то я могу накинуть больше контекста
1) Обратимся к первоисточнику
Согласно ITIL® 4, SLA - это "документально подтвержденное соглашение между поставщиком услуг и клиентом, в котором зафиксированы как необходимые услуги, так и ожидаемый уровень обслуживания". Такие соглашения могут быть как формальными, так и неформальными.
По тексту
Хорошо, если у Ивана есть какие-то SLA требования к системе, которую он будет нагружать, зачастую этого тоже нет. И вот у Ивана есть какой-то инструмент, какой-то стенд для нагрузочного тестирования, какие-то SLA
Поэтому и возник вопрос - что в данном случае подразумевается под SLA ?
Предположу имеется в виду что-то типа - "отклик системы", "количество запросов в секунду", "количество пользователей". Вот потому и возникло дополнение
Может быть корректнее использовать термин "граничное условие" (thresholds) ?
SLA все таки это несколько другое
2) Ну вот в результате нагрузочного тестирования получены наборы цифр. Проводится ли статистический анализ - мат.ожидание, дисперсия, медианное значение, мода . Ну например
- проведено 100 прогонов НТ с разным количеством пользователей в системе. Как определить влияние количества пользователей на итоговую производительность ?
-внесены изменения в код приложения. Как изменения повлияли на производительность.
Может быть я не совсем внимательно прочитал , но
Теперь поговорим про сравнение результатов. Всего в сервисе load-testing-hub есть два вида сравнения:
Сравнение текущего результата, со значениями предыдущего результата и со средними значениями для сервиса/сценария.
Сравнение текущего результата с SLA.
Это маловато для анализа результатов. А использовать среднее анализа рискованно . Среднее значение сильно подвержено выбросам. К тому, же например среднее время отклика СУБД в принципе не может быть использовано для оценки производительности СУБД .
Поэтому и возник вопрос - "Проводится ли статистическая обработка результатов? " - может я невнимательно прочитал, пропустил что-то .
3) Вот эти примеры , с конкретными цифрами - очень интересны
Сравнивать результаты НТ c фактическими данными и с желаемыми SLA, на основе этих данных мы можем делать вывод о деградации и аномалиях в производительности сервиса.
вот здесь очень интересен реальный пример из жизни.
Спасибо.
Предположу имеется в виду что-то типа - "отклик системы", "количество запросов в секунду", "количество пользователей". Вот потому и возникло дополнение
Да, именно это и имелось ввиду) Возможно термин SLA тут был не уместен, можно было просто написать "требования". Тут скорее локальное употребление этого термина, возможно знаете ситуации, когда все в команде/компании используют термин, никто не знает его точно определение, но все понимают о чем вы)
Это маловато для анализа результатов. А использовать среднее анализа рискованно . Среднее значение сильно подвержено выбросам. К тому, же например среднее время отклика СУБД в принципе не может быть использовано для оценки производительности СУБД .
Поэтому и возник вопрос - "Проводится ли статистическая обработка результатов? " - может я невнимательно прочитал, пропустил что-то .
Результаты сравниваются с желаемыми требованиями, я писал про это в разделе Results про сравнения
Сравнение текущего результата с SLA. Тут все предельно просто, данный параметр показывает отклонение от заданных в сценарии SLA. Позже рассмотрим, как задаются SLA для сценария. Данный параметр статичен, в отличие от предыдущих и средних значений. Например, сервис начал деградировать и с каждым новым релизом среднее и предыдущие значения будут только ухудшаться, но SLA останутся теми же, что позволит нам объективно оценивать производительность
Вы правильно заметили, более глубокого анализа пока не делается, но думаю над этим точно стоит подумать)
Вот эти примеры , с конкретными цифрами - очень интересны
Мы работаем над банковским приложением, конкретно моя команда занимается отображением виджетов на главной странице и лентой операций, а это самая высоко нагруженная часть в мобильном приложении. Если будут проблемы с загрузокой аккаунтов, кешбэков, подписок, операций, рассрочек, то приложением невозможно будет пользоваться, поэтому стабильность наших микросервисов очень критична
Наш продукт пока активно растет и развивается, но на проде уже нагрузка доходит до 20-30 RPS в обычные дни, 130-150 RPS в пики, это происходит в начале месяца при выборе категорий кешбэка, при каких-либо акциях, либо рекламных кампаниях. Сейчас мы нагружаем наши сервисы, с нагрузкой ~ X10 от продовской в пике. Также есть заранее созданные данные - операции, которых на текущий момент ~60KK, это в 3-4 раза больше чем на проде, то есть мы грузим не пустую базу данных
Также задача нагрузки у нас очень не тривиальная, т.к. наша команда интегрируется с огромным количеством внешних сервисов, примерно 30 внешних сервисов. Все это нужно мокать, при этом имитировать время ответа внешнего сервиса
Ну и собственно весь процесс нагрузочного тестирования автоматизирован и в этой статье я, как раз рассказывал про сервис, который аггрегирует всю информацию касаемо результатов НТ и визуализирует информацию команде
Шикарная статья. Спасибо автору. Возник вопрос выложенный код сервиса load-testing-hub нужно ложить на свой сервер для работы с ним или как он работает?
Да, все верно! Чтобы сервис load-testing-hub работал, нужно на своем сервере/кластере/виртуальной машине/в облаке раздеплоить API часть load-testing-hub-api и UI часть load-testing-hub-panel
собрал два образа по прикрепленному Dockerfile, ни один не запускается, логи чистые.
Я так понимаю запуск сервиса в контейнерах не отлажен?
Эти докер образы предназначены для кубера, как запустить локально я описал в ридмишках
https://github.com/Nikita-Filonov/load-testing-hub-panel/blob/main/README.md
https://github.com/Nikita-Filonov/load-testing-hub-api/blob/main/README.md
Базу постгреса соотвественно нужно будет поднять либо локально, либо в докере, как вам удобно
Спасибо большое за статью, очень многое для себя почерпнул.
Правильный инструмент для аналитики нагрузочного тестирования