А можно уточнить - в чем заключается тестирование ?
Я просто уже сколько времени пытаюсь придумать задачу в которой бот ии помогал бы DBA(неджуну). Пока не получается, найти какую то тему в которой ии был был бы реально полезен.
Задавать серьёзные вопросы ии - нет смысла . В ответ будет анекдот про студента на экзамене по биологии.
А документацию быстрее обычным поиском пролистать , а какие то особенности в книге бумажной анализировать. Ну, по крайней мере мне.
P.S. Кстати да , если один вопрос задать разным ботам, легко найти паттерны в ответах.
Да, тут согласен. Название не принципиально , назовем sql-statement . Просто , это не является каким то скрытым знанием , характер производительности СУБД при select, insert, update сильно разный.
Поэтому мы и предлагаем каждому тестировать БД под свои нагрузки
Да тема нагрузочного тестирования и особенно анализ результатов давно в работе.
Выскажу мысль, что тестирование скорости СУБД в облаке занятие неблагодарное . Очень сильноизменяемая инфраструктура в облаке . Сегодня одни результаты завтра другие , потому что виртаулизаторы что там в очередной раз изменили .
В результате имеем то, что имеем - в ходе реализации импортозамещения 100% продуктов созданных по самым передовым методикам имеют 100% проблем как только передаются в опытную эксплуатацию. И всегда "ой у нас все тормозит".
"Люди и взаимодействие важнее, чем инструменты и процессы.", "Рабочий продукт важнее документации"
Эти два постулата лично меня всегда особенно веселили :-)
Фигня война , главное - маневры ;-)
аджайл почти идеальный инструмент на R&D, когда приходит клиент,
В моем случае все информационные системы это Business2Business.
Клиента как такового нет, есть бюджет, максимально размытый и непонятный ТР и так далее.
Когда то давным давно , когда я работал в одном банке, разработчики одной информационной системы, тогда это называлось "Опердень банка", очень часть употребляли стандартный рекламный слоган - "Наша система лучшая по соотношению цена-качество".
Мы в ответ, громко смеялись - "ребята это банк, тут деньги считают, качество должно быть МАКСИМАЛЬНЫМ. Ошибок, округлений, приближений, потерь данных не может быть В ПРИНЦИПЕ".
Не бывает осетрины второй свежести. Свежесть осетрины только первая, она же и последняя(c).
BTW, просто любопытно , вопрос от не знатока agile - а вообще , мероприятия performance test -> tuning -> improvement предусмотрены методологией ?
Или , как я понял - разработка отдельно, сопровождение и развитие отдельно ?
Судя по всему , второе, наверное больше половины проблем с производительностью можно было бы избежать, если бы об этом подумали на этапе дизайна и разработки и если бы нагрузочное тестирование проводилось на этапе разработки.
Ну получается эта проблема у ВСЕХ product owners из тех , чти продукты потом приходится сопровождать . Я не знаю , как положено по agile, я повторюсь вышел из секты.
Та тема и продукт который я веду, классический waterfall - Я якудза старой школы.
Как однажды затянутый в секту - подписываюсь под каждым словом. Но мне повезло , я вырвался .
Про "waterfall" - в самую точку . Их реально корежить начинает.
Первые сомнения появились когда в ответ на вопрос "когда мы начнем заниматься нагрузочным тестированием и оптимизацией производительности ?" , я получил ответ product owner - "а это не наша задача , не по аджайл, этим будет другая команда сопровождения заниматься. Наша задача закрыть спринты и передать продукт в эксплуатацию".
А потом они просто взяли и перешли на ORM полностью похерив предыдущую модель "бизнес логика в СУБД". Зато , я вырвался из секты .
В результате имеем то, что имеем - в ходе реализации импортозамещения 100% продуктов созданных по самым передовым методикам имеют 100% проблем как только передаются в опытную эксплуатацию. И всегда "ой у нас все тормозит".
Продолжали бы писать на хабр технические статьи и не скатывались в политику
Я уж не знаю как мне ещё раз то же самое сказать громко, чтобы поставить точку - мне сливали карму за технические статьи на тему статистического анализа производительности СУБД.
Ещё раз - сливали карму за технические статьи . Ведь не поленюсь найду статью написанную в режиме recovery. А вы найдёте политику в статье или комментариях ?
И известный афоризм
Скоро заиграет новыми красками .
Ну например
А можно уточнить - в чем заключается тестирование ?
Я просто уже сколько времени пытаюсь придумать задачу в которой бот ии помогал бы DBA(неджуну). Пока не получается, найти какую то тему в которой ии был был бы реально полезен.
Задавать серьёзные вопросы ии - нет смысла . В ответ будет анекдот про студента на экзамене по биологии.
А документацию быстрее обычным поиском пролистать , а какие то особенности в книге бумажной анализировать. Ну, по крайней мере мне.
P.S. Кстати да , если один вопрос задать разным ботам, легко найти паттерны в ответах.
Тем , что система ляжет , при нагрузке выше среднего .
Я в свое время пытался понять логику разрабов - зачем они используют select for update .
Объяснений так и не получилось получить ибо ORM. А как работает субд они не в курсе .
Да, тут согласен. Название не принципиально , назовем sql-statement . Просто , это не является каким то скрытым знанием , характер производительности СУБД при select, insert, update сильно разный.
Да тема нагрузочного тестирования и особенно анализ результатов давно в работе.
Если любопытно:
https://dzen.ru/a/Z7gmHgBGAHo5m2SS
Выскажу мысль, что тестирование скорости СУБД в облаке занятие неблагодарное . Очень сильноизменяемая инфраструктура в облаке . Сегодня одни результаты завтра другие , потому что виртаулизаторы что там в очередной раз изменили .
Ок, вечером прочитаю еще раз повнимательнее.
Со средним арифметическим есть серьезная проблема
https://dzen.ru/a/Z1--cZ4sHEmzLsy5
Я просто на грабли среднего арифметического уже наступал.
Так, что цифрам TPS которые показывает pgbench , я уже давно не доверяю. Потому, что выбросы это норма, особенно, кстати в облачной инфраструктуре.
А если транзакций нет вообще ? Только select .
Да и транзакция транзакции рознь.
INSERT и UPDATE выполняются в транзакции, но вот влияние на работу СУБД очень сильно отличается .
Не только, еще и тяжелые и легкие блокировки.
А есть еще репликация и ожидания IPC.
Почему ?
Я использую медиану. Что-то мне подсказывает, что 99 персентиль скакать будет очень.
Спасибо за комментарий.
В общем то было понятно по жизни
Эти два постулата лично меня всегда особенно веселили :-)
Фигня война , главное - маневры ;-)
В моем случае все информационные системы это Business2Business.
Клиента как такового нет, есть бюджет, максимально размытый и непонятный ТР и так далее.
Самый главный вопрос - как рассчитывается производительность ? Что понимается под производительностью СУБД ?
Почему вы так уверены ?
Результат считали как среднее арифметическое ? Время отклика запроса - как рассчитывали?
Среднее арифметическое ?
Сколько всего получилось итераций ?
В гранит !
Одно время , я часто слышал от разрабов - мы будем переходить на микросервисную архитектуру .
Оказалось , они под микросервисной архитектуры понимают кучу бд в одном экземпляре СУБД к которым коннектится backend.
Зато теперь могут всем говорить - наша информационная система построена на микросервисной архитектуре .
Вы наверное и не застали времена когда "Опердень банка" писали на Access.
И оно работало.
Но недолго .
Потом пришел DBase работать стал дольше.
И только потом , пришел Оракл .
Когда то давным давно , когда я работал в одном банке, разработчики одной информационной системы, тогда это называлось "Опердень банка", очень часть употребляли стандартный рекламный слоган - "Наша система лучшая по соотношению цена-качество".
Мы в ответ, громко смеялись - "ребята это банк, тут деньги считают, качество должно быть МАКСИМАЛЬНЫМ. Ошибок, округлений, приближений, потерь данных не может быть В ПРИНЦИПЕ".
Не бывает осетрины второй свежести. Свежесть осетрины только первая, она же и последняя(c).
Вот так новость !
BTW, просто любопытно , вопрос от не знатока agile - а вообще , мероприятия performance test -> tuning -> improvement предусмотрены методологией ?
Или , как я понял - разработка отдельно, сопровождение и развитие отдельно ?
Судя по всему , второе, наверное больше половины проблем с производительностью можно было бы избежать, если бы об этом подумали на этапе дизайна и разработки и если бы нагрузочное тестирование проводилось на этапе разработки.
And so what ?
Никто из тех кто принимает решения не читает хабр, и о вашем существовании в принципе не знает.
Просто любопытно - зачем тратить на это время , силы и нервы ?
Ну наберете вы на хабре плюсы, минусы и что изменится ?
Ну получается эта проблема у ВСЕХ product owners из тех , чти продукты потом приходится сопровождать . Я не знаю , как положено по agile, я повторюсь вышел из секты.
Та тема и продукт который я веду, классический waterfall - Я якудза старой школы.
Как однажды затянутый в секту - подписываюсь под каждым словом. Но мне повезло , я вырвался .
Про "waterfall" - в самую точку . Их реально корежить начинает.
Первые сомнения появились когда в ответ на вопрос "когда мы начнем заниматься нагрузочным тестированием и оптимизацией производительности ?" , я получил ответ product owner - "а это не наша задача , не по аджайл, этим будет другая команда сопровождения заниматься. Наша задача закрыть спринты и передать продукт в эксплуатацию".
А потом они просто взяли и перешли на ORM полностью похерив предыдущую модель "бизнес логика в СУБД". Зато , я вырвался из секты .
В результате имеем то, что имеем - в ходе реализации импортозамещения 100% продуктов созданных по самым передовым методикам имеют 100% проблем как только передаются в опытную эксплуатацию. И всегда "ой у нас все тормозит".
Вот вам яндекс (я не знаю как в гугле давно не пользуюсь)
Вполне себе технический запрос и ответ.
Потому, что заблокировали. Вроде .
Или уже нет ?
Однако, ещё раз убеждаюсь - правильно сделал , что перестал публиковаться на Хабре.
Я уж не знаю как мне ещё раз то же самое сказать громко, чтобы поставить точку - мне сливали карму за технические статьи на тему статистического анализа производительности СУБД.
Ещё раз - сливали карму за технические статьи . Ведь не поленюсь найду статью написанную в режиме recovery. А вы найдёте политику в статье или комментариях ?
Вот
Влияние vacuum/analyze/bloat на производительность СУБД https://habr.com/p/845454/
А теперь найдите политику пропаганду в предыдущих статьях и комментариях .
И ответить на вопрос - а зачем мне это надо - выкладывать статьи на Хабре ?