Comments 8
Использование коротких периодов для выполнения тестов - не позволяет получить достоверные итоговые результаты.
Чегой-то не позволяет? Приложение не с медианными сглаженными откликами работает, а с теми, которые есть в реальном времени. И вот эти все сглаживания с большими периодами - классическая средняя температура по больнице, которая вообще бесполезна в ответе на вопрос "жив ли конкретный пациент".
Вот результаты производительности без сглаживания.
Проход 1:
min = 184
max = 17846
Среднее = 1721
Проход 2:
min = 155
max = 3139
Среднее = 1656
Вопрос - какое значение будете использовать для оценки производительности СУБД ?
Без ответа на вопрос "какая метрика важна для приложения" - никакую, разумеется. Если вас интересует исключительно план по валу типа "сколько транзакций БД способна переварить за сутки" - это одно, но в реальной жизни это куда более редкий сценарий, чем необходимость стабильно низкого времени отклика, а в таких случаях надо смотреть не на средний TPS, а на распределение и процент выпадения латентности из целевого диапазона. И, надеюсь, понятно, что усреднение тут никакой реальной картины не покажет.
Без ответа на вопрос "какая метрика важна для приложения" - никакую, разумеется.
Метрика ради которой собственно все и происходит "Производительность СУБД".
Но если такой метрики нет, то "TPS"
надеюсь, понятно, что усреднение тут никакой реальной картины не покажет.
Нет не понятно. На чем основано данное утверждение?
Я опираюсь на цифры , полученные в результате использования методов статистического анализа , доказавших свою эффективность, не одну сотню лет.
Чем вы докажете свои утверждения?
Метрика ради которой собственно все и происходит "Производительность СУБД".
Нет такой метрики, потому что нет никакого общепринятого единого определения, что же такое "производительность СУБД". Вот TPS - есть, время отклика - есть, время исполнения типового сложного запроса - тоже вполне может быть. А абстрактная "производительность" без указания измеримых величин - нет.
На чем основано данное утверждение?
На опыте работы с ситуациями, когда "в среднем по больнице" все прекрасно, все усредненные метрики "зеленые", а бизнес-пользователи приходят с жалобами на низкую производительность.
Подробнее, если интересно https://habr.com/ru/posts/827260/
И там у вас написано что-то совершенно оторванное от реальной практики применения СУБД. Цитирую:
И вот , ситуация изменилась - запросов OLTP стало меньше , но появились аналитические/долгие запросы .
В результате значение метрики увеличивается - запросов стало меньше , общее время выполнения увеличилось.
Является ли данная ситуация алертом для создания инцидента о деградации производительности СУБД ?
Конечно же - нет.
Конечно же, ДА, и это знает примерно любой человек, который на практике обслуживал более-менее крупные системы со "смешанным" типом нагрузок, например, бухгалтерию. Там вот кто-то запускает большой аналитический отчет, и в техподдержку прибегает толпа взъерошенных тетенек со словами "работать невозможно, а у нас закрытие периода". И если админ будет тыкать им "средней производительностью", его быстро вразумят либо сами тетеньки, либо собственное руководство. После чего его таки обычно (хотя и не всегда) настигает понимание, что если бизнес-задача требует хорошего времени отклика, то падение оного при запуске каких-то других задач - это именно что деградация производительности, в самом прямом смысле, даже несмотря на то, что чисто технически СУБД работает "нормально" и ни в ней, ни в железе ничего не сломалось. И это повод не отказываться от ключевой метрики, а пересматривать параметры решения таким образом, чтобы вернуть ее обратно в норму - например, использовать для аналитики отдельные копии БД, увеличивать выделенные серверу СУБД ресурсы, и т.п.
Ваш же подход имеет какой-то практический смысл либо тогда, когда именно с точки зрения логики конечной задачи интересна только валовая производительность на больших периодах времени, либо когда собственно бизнес-задачи, которые обслуживает эта СУБД, вас вообще не интересуют, а вы хотите следить именно за ее чисто техническим состоянием (грубо говоря, не сломалось ли что-то в самой СУБД или нижележащем слое ОС/железа). Но и в последнем случае использовать сглаживание с периодом в час - это стрелять себе в ногу, потому что в реальной жизни деградацию обычно крайне желательно видеть за минуты, а не за часы.
Нет такой метрики, потому что нет никакого общепринятого единого определения, что же такое "производительность СУБД".
Есть и метрика и определение.
Производительность — это объём работы, выполняемый за единицу времени (например, за час или за день). По-другому, это скорость выполнения работы.
Работа СУБД это чтение/запись/изменение информации.
А абстрактная "производительность" без указания измеримых величин - нет.
Если вы чего не не знаете, не используете из этого никак не следует, что этого нет.
и это знает примерно любой человек, который на практике обслуживал более-менее крупные системы со "смешанным" типом нагрузок, например, бухгалтерию
Спасибо за обратную связь. Дальше, нет смысла тратить время .
Работа СУБД это чтение/запись/изменение информации.
Измеряемая в каких единицах? Вы в измерениях используете примитивный тест, меряющий TPS, но при этом спорите со мной, что у вас какое-то иное определение производительности? :) Ну так примерно все вокруг делают то же самое, только паттерны нагрузки часто используют более продвинутые и в обязательном порядке к результатам TPS добавляют response time с перцентилями.
Дальше, нет смысла тратить время .
А вы поясните, в чем практический смысл вашей методики измерения и для каких реальных сценариев она применима. Пока что по откликам к вашим статьям все выглядит так, что нет смысла тратить время на вас, ибо вся суть вашего подхода выглядит как "мне не нравятся эти пиковые выбросы, это не производительность". Из двух общепринятых критических показателей производительности OLTP баз (TPS и response time) вы предлагаете использовать только один, причем еще и усреднять по большим периодам. Зачем? Какой конечной цели вы хотите добиться, ответ на какие практические вопросы получить? Мне действительно интересно.
необходимость стабильно низкого времени отклика
Время отклика СУБД не является индикатором состояния СУБД. Мы не используем эту метрику уже давно.
Причина - подтвержденность ошибкам 1-го и 2-го рода.
Подробнее, если интересно https://habr.com/ru/posts/827260/
Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат