Короткое дополнение , в связи с ограниченными размером поста.
По итогам экспериментов , можно предположить , что существует как минимум 1 вид инфраструктуры в котором данное утверждение бесспорно - облачное хранилище данных.
Постоянная нагрузка на СУБД на долгом промежутке времени дает весьма существенный разброс итоговой производительности. Более того - характер ожиданий СУБД меняется весьма заметно.
Согласно ITIL® 4, SLA - это "документально подтвержденное соглашение между поставщиком услуг и клиентом, в котором зафиксированы как необходимые услуги, так и ожидаемый уровень обслуживания". Такие соглашения могут быть как формальными, так и неформальными.
По тексту
Хорошо, если у Ивана есть какие-то SLA требования к системе, которую он будет нагружать, зачастую этого тоже нет. И вот у Ивана есть какой-то инструмент, какой-то стенд для нагрузочного тестирования, какие-то SLA
Поэтому и возник вопрос - что в данном случае подразумевается под SLA ?
Предположу имеется в виду что-то типа - "отклик системы", "количество запросов в секунду", "количество пользователей". Вот потому и возникло дополнение
Может быть корректнее использовать термин "граничное условие" (thresholds) ?
SLA все таки это несколько другое
2) Ну вот в результате нагрузочного тестирования получены наборы цифр. Проводится ли статистический анализ - мат.ожидание, дисперсия, медианное значение, мода . Ну например
- проведено 100 прогонов НТ с разным количеством пользователей в системе. Как определить влияние количества пользователей на итоговую производительность ?
-внесены изменения в код приложения. Как изменения повлияли на производительность.
Может быть я не совсем внимательно прочитал , но
Теперь поговорим про сравнение результатов. Всего в сервисе load-testing-hub есть два вида сравнения:
Сравнение текущего результата, со значениями предыдущего результата и со средними значениями для сервиса/сценария.
Сравнение текущего результата с SLA.
Это маловато для анализа результатов. А использовать среднее анализа рискованно . Среднее значение сильно подвержено выбросам. К тому, же например среднее время отклика СУБД в принципе не может быть использовано для оценки производительности СУБД .
Поэтому и возник вопрос - "Проводится ли статистическая обработка результатов? " - может я невнимательно прочитал, пропустил что-то .
3) Вот эти примеры , с конкретными цифрами - очень интересны
Сравнивать результаты НТ c фактическими данными и с желаемыми SLA, на основе этих данных мы можем делать вывод о деградации и аномалиях в производительности сервиса.
вот здесь очень интересен реальный пример из жизни.
Можно же отказаться от ORM, верно?) Ну или на худой конец поменять саму ORM на более вменяемую
В современных условиях это невозможно . Повторюсь - современное поколение разработчиков просто не умеет писать запросы и разрабатывать архитектуру СУБД без ORM и библиотек .
Я помню как они удивлялись - "а какая библиотека была использована для реализации графа и обхода дерева ? Да никакая , взял и написал алгоритмы , вспомнил 2й курс КАИ и теорию графов". Для них был шок, что можно самому что то сделать.
Может быть это мне не везёт. С разрабами , но 4й год одно и тоже - ORM + "у нас фреймворк такой". и всегда - как только пошла промышленная нагрузка -"мы уперлись в СУБД , дайте нам волшебную комбинацию конфигурационных параметров ".
Я же не просто так занялся темой производительности СУБД - теперь я могу доказать средствами объективного контроля - "с СУБД аномалий нет идите разбирайтесь со своим приложением".
производительность — это объем работы в единицу времени, а стоимость — это оценка общего объема работы
В этом то и состоит предположение, которое нужно проверить
отношение стоимости запроса (EXPLAIN ANALYSE) к актуальному времени выполнения запроса .
Поделив стоимость плана выполнения запроса(общий объем) на актуальное время выполнения можно получить оценку производительности.
Да, результирующая цифра будет не согласована с метрикой производительности (пока не знаю порядок различия , нужны эксперименты). Но для оценки наверное будет достаточно. Можно будет точно сказать, например - как конкретные параметры влияют на оценку производительности . Например - как изменится производительность, если количество результирующих строк запроса увеличится на 10, 15, 20, 50% . Дальше , предположу - ждет масса весьма интересных экспериментальных данных. Ну например - какое соединение больше зависит от объёма обрабатываемых строк - Hash или Merge ? Как влияет сортировка ? Понятно , что и вид соединения и использование сортировки влияет - но вопрос - на сколько конкретно ? И как это влияние зависит от объёма ? И это только вопросы , которые вот сразу пришли в голову . А сколько еще интересного будет , если подготовится заранее .
И т.д. и т.п. , посмотрим , что покажут эксперименты .Или я плохо искал , но пока подобных исследований не встречал. Поэтому , тема интересная обещает быть .
Я помню как всё начиналось. Какие были надежды. Как, часто бывает по жизни - идея была сделать мир лучше , а в результате в мир выпустили монстра. Они думают, что управляют чудовищем, а на самом деле чудовище управляет и полностью подчиняет себе создателя .
В результате - план запроса стоимостью триллион и вопрос разработчика к DBA - а почему он так медленно работает ? Мальчик, а на что ты надеялся с сотней джойнов, вложенными подзапросами, группировками и сортировкой ? И искреннее удивление - это не я , это ORM.
за разработку в БД и оптимизацию запросов отвечает DBA который НЕ РАЗРАБОТЧИК
Эх, прям соль на рану. Сколько нервов , времени требуется чтобы довести эту простую мысль до разрабов и руководство их.
Абсурдная ситуация - DBA никак не участвуют в процессе разработки , но 100% как начинается промышленная эксплуатация всегда начинается - ой у нас всё медленно работает , мы уперлись в СУБД.
По ходу проведения импортозамещения с адекватными и профессиональными разработчиками большие проблемы .
Повторяюсь, сорри, но для них СУБД это хранилка данных. Как работает СУБД они не знают и знать не хотят .
В результате - "у нас проблемы с СУБД , очень много ожиданий Client read" , или "вы зачем используете эксклюзивные блокировки ? Это не мы у нас фреймворк такой" и т.д. и т.п. Ну а про то , какие запросы генерят ORM это отдельная тема . Я лично видел план запроса стоимостью триллион (10^12) и вопрос руководителя разрабов - "почему у нас медленно открывается форма "
Раньше было даже смешно и прикольно . Но когда происходит срыв сроков и постоянные аварии уже не смешно - "У нас проблемы с импортозамещением."
А с хранимками ситуация очень простая - современные разработчики просто не умеют писать бизнес логику в СУБД. Все наработки предыдущих поколений спустили в трубу в угоду моде и трендам.
На одном проекте, разработчики backend - в очереди стояли , набор вообще без проблем , на любой вкус и цвет. Разработчика СУБД искали год . Нашли с большим трудом.
Вот и приходится писать бизнес логику , ролевую модель , ограничения целостности и корректности данных , фильтрацию и агрегацию в приложении, а не в СУБД и придумывать оправдания типа "хранимки это рудимент".
Разница в том, что ваш комментарий по идеальному миру и по книжкам и курсам.
Мой , по реальной жизни.
Может быть , компании в которых вы работаете/работали действительно такие как вы описали . Я говорю только о себе и своем опыте.
Вы невнимательно прочитали мой комментарий .
На руководящей должности основное время был занят объяснением что белое это белое а из навоза и палочек дом не построить. Я продержался 3 года . Но повторюсь , все симптомы выгорания у меня были . Я изменил образ жизни , я повторюсь, сто тысяч раз себе молодец.
Мне не нужна похвала от менеджера или клиента , особо меня раздражало - "да мы понимаем , что мы работаем неправильно , но менять ничего не будем." Меня хватило на 3 года .
Теперь я занимаюсь инженерной работой и как там менеджеры трутся между собой - мне все равно.
P.S. Я , как DBA никогда не работал с конечными клиентами , всю жизнь я общаюсь именно с манагерами самых разнообразных форм и расцветок .
Время отклика СУБД не является индикатором состояния СУБД. Мы не используем эту метрику уже давно.
Причина - подтвержденность ошибкам 1-го и 2-го рода.
Подробнее, если интересно https://habr.com/ru/posts/827260/
Метрика ради которой собственно все и происходит "Производительность СУБД".
Но если такой метрики нет, то "TPS"
Нет не понятно. На чем основано данное утверждение?
Я опираюсь на цифры , полученные в результате использования методов статистического анализа , доказавших свою эффективность, не одну сотню лет.
Чем вы докажете свои утверждения?
Вот результаты производительности без сглаживания.
Проход 1:
min = 184
max = 17846
Среднее = 1721
Проход 2:
min = 155
max = 3139
Среднее = 1656
Вопрос - какое значение будете использовать для оценки производительности СУБД ?
Как говорится - подписываюсь под каждым словом, именно так по реальной жизни происходит.
IMHO только один сценарий - pbench на физических серверах.
Однако есть одна очень серьезная проблема - объяснить все это манагерам и разрабам.
По личному опыту , это очень серьезная проблема , цитат и перлов можно привести не на одну статью.
А почему для тестов выбран столь короткий промежуток времени ?
Не проводились ли аналогичные замеры , но за более долгий период ? Например 1 час ?
Есть уверенность , и на чем она основана, что на результаты не повлиял шум ?
Почему так мало итераций ?
Под усреднением подразумевается "среднее арифметическое" ?
Не кажется ли автору , что для столь серьёзных выводов было выполнено недостаточное количество столь коротких тестовых замеров ?
Короткое дополнение , в связи с ограниченными размером поста.
По итогам экспериментов , можно предположить , что существует как минимум 1 вид инфраструктуры в котором данное утверждение бесспорно - облачное хранилище данных.
Постоянная нагрузка на СУБД на долгом промежутке времени дает весьма существенный разброс итоговой производительности. Более того - характер ожиданий СУБД меняется весьма заметно.
Именно по этому статья и вызвала интерес. Взял в закладки.
1) Обратимся к первоисточнику
По тексту
Поэтому и возник вопрос - что в данном случае подразумевается под SLA ?
Предположу имеется в виду что-то типа - "отклик системы", "количество запросов в секунду", "количество пользователей". Вот потому и возникло дополнение
SLA все таки это несколько другое
2) Ну вот в результате нагрузочного тестирования получены наборы цифр. Проводится ли статистический анализ - мат.ожидание, дисперсия, медианное значение, мода . Ну например
- проведено 100 прогонов НТ с разным количеством пользователей в системе. Как определить влияние количества пользователей на итоговую производительность ?
-внесены изменения в код приложения. Как изменения повлияли на производительность.
Может быть я не совсем внимательно прочитал , но
Это маловато для анализа результатов. А использовать среднее анализа рискованно . Среднее значение сильно подвержено выбросам. К тому, же например среднее время отклика СУБД в принципе не может быть использовано для оценки производительности СУБД .
Поэтому и возник вопрос - "Проводится ли статистическая обработка результатов? " - может я невнимательно прочитал, пропустил что-то .
3) Вот эти примеры , с конкретными цифрами - очень интересны
вот здесь очень интересен реальный пример из жизни.
Спасибо.
Спасибо за статью, взял в закладки. Возникло 3 вопроса:
1) Что понимается под термином SLA ?
IMHO "SLA" это аббревиатура от стандартного термина в ITIL : "Service Level Agreement".
Может быть корректнее использовать термин "граничное условие" (thresholds) ?
2) Проводится ли статистическая обработка результатов?
3) А можно примеры из жизни ?
Прошло 8 лет. Версия СУБД - не менялась ?
Версия PostgreSQL = 9.6 это не опечатка ?
Чем обусловлено использование столь старой версии СУБД ?
В современных условиях это невозможно . Повторюсь - современное поколение разработчиков просто не умеет писать запросы и разрабатывать архитектуру СУБД без ORM и библиотек .
Я помню как они удивлялись - "а какая библиотека была использована для реализации графа и обхода дерева ? Да никакая , взял и написал алгоритмы , вспомнил 2й курс КАИ и теорию графов". Для них был шок, что можно самому что то сделать.
Может быть это мне не везёт. С разрабами , но 4й год одно и тоже - ORM + "у нас фреймворк такой". и всегда - как только пошла промышленная нагрузка -"мы уперлись в СУБД , дайте нам волшебную комбинацию конфигурационных параметров ".
Я же не просто так занялся темой производительности СУБД - теперь я могу доказать средствами объективного контроля - "с СУБД аномалий нет идите разбирайтесь со своим приложением".
Спасибо за конструктивный комментарий .
В этом то и состоит предположение, которое нужно проверить
Поделив стоимость плана выполнения запроса(общий объем) на актуальное время выполнения можно получить оценку производительности.
Да, результирующая цифра будет не согласована с метрикой производительности (пока не знаю порядок различия , нужны эксперименты). Но для оценки наверное будет достаточно. Можно будет точно сказать, например - как конкретные параметры влияют на оценку производительности . Например - как изменится производительность, если количество результирующих строк запроса увеличится на 10, 15, 20, 50% . Дальше , предположу - ждет масса весьма интересных экспериментальных данных. Ну например - какое соединение больше зависит от объёма обрабатываемых строк - Hash или Merge ? Как влияет сортировка ? Понятно , что и вид соединения и использование сортировки влияет - но вопрос - на сколько конкретно ? И как это влияние зависит от объёма ? И это только вопросы , которые вот сразу пришли в голову . А сколько еще интересного будет , если подготовится заранее .
И т.д. и т.п. , посмотрим , что покажут эксперименты .Или я плохо искал , но пока подобных исследований не встречал. Поэтому , тема интересная обещает быть .
ORM да , это определённый водораздел.
Я помню как всё начиналось. Какие были надежды. Как, часто бывает по жизни - идея была сделать мир лучше , а в результате в мир выпустили монстра. Они думают, что управляют чудовищем, а на самом деле чудовище управляет и полностью подчиняет себе создателя .
В результате - план запроса стоимостью триллион и вопрос разработчика к DBA - а почему он так медленно работает ? Мальчик, а на что ты надеялся с сотней джойнов, вложенными подзапросами, группировками и сортировкой ? И искреннее удивление - это не я , это ORM.
Эх, прям соль на рану. Сколько нервов , времени требуется чтобы довести эту простую мысль до разрабов и руководство их.
Абсурдная ситуация - DBA никак не участвуют в процессе разработки , но 100% как начинается промышленная эксплуатация всегда начинается - ой у нас всё медленно работает , мы уперлись в СУБД.
Ключевое слово адекватный.
По ходу проведения импортозамещения с адекватными и профессиональными разработчиками большие проблемы .
Повторяюсь, сорри, но для них СУБД это хранилка данных. Как работает СУБД они не знают и знать не хотят .
В результате - "у нас проблемы с СУБД , очень много ожиданий Client read" , или "вы зачем используете эксклюзивные блокировки ? Это не мы у нас фреймворк такой" и т.д. и т.п. Ну а про то , какие запросы генерят ORM это отдельная тема . Я лично видел план запроса стоимостью триллион (10^12) и вопрос руководителя разрабов - "почему у нас медленно открывается форма "
Раньше было даже смешно и прикольно . Но когда происходит срыв сроков и постоянные аварии уже не смешно - "У нас проблемы с импортозамещением."
А с хранимками ситуация очень простая - современные разработчики просто не умеют писать бизнес логику в СУБД. Все наработки предыдущих поколений спустили в трубу в угоду моде и трендам.
На одном проекте, разработчики backend - в очереди стояли , набор вообще без проблем , на любой вкус и цвет. Разработчика СУБД искали год . Нашли с большим трудом.
Вот и приходится писать бизнес логику , ролевую модель , ограничения целостности и корректности данных , фильтрацию и агрегацию в приложении, а не в СУБД и придумывать оправдания типа "хранимки это рудимент".
Все просто .
Данное утверждение будет верно только при одном важном уточнении - читатель и отладчик не обладает знаниями Database Development .
Что и подтверждается следующим утверждением
А можно подробнее ? Что значит "статус расширения"?
Разница в том, что ваш комментарий по идеальному миру и по книжкам и курсам.
Мой , по реальной жизни.
Может быть , компании в которых вы работаете/работали действительно такие как вы описали . Я говорю только о себе и своем опыте.
Вы невнимательно прочитали мой комментарий .
Мне не нужна похвала от менеджера или клиента , особо меня раздражало - "да мы понимаем , что мы работаем неправильно , но менять ничего не будем." Меня хватило на 3 года .
Теперь я занимаюсь инженерной работой и как там менеджеры трутся между собой - мне все равно.
P.S. Я , как DBA никогда не работал с конечными клиентами , всю жизнь я общаюсь именно с манагерами самых разнообразных форм и расцветок .
В точку ! Именно так происходит в реальной жизни.
-Система не прошла нт и не может быть принята в тех.поддержку ? Не важно, нам надо закрыть этап договора . Исправлять будем потом .