Comments 8
1) В приведённом алгоритме решений оптимизации отсутствует принципиально важный пункт - нагрузочное тестирование и анализ результатов изменений
2)
База данных — это бутылочное горлышко. Начинайте оптимизацию оттуда. Индексы и EXPLAIN дают 80% результата за 20% усилий.
За 5 лет участия во внедрении новых информационных систем в ходе реализации программы импортозамещения ни разу не было прецедента когда критичные проблемы оптимизации работы информационной системы были решены с помощью создания индексов .
По личному опыту решения проблем информационных систем , корневые причины деградации производительности:
90% - проблемы логики приложений
8% - проблемы инфраструктуры
2% - неоптимальная настройка конфигурационных параметров СУБД
P.S. По итогам последних экспериментов и исследований - решения принятые на основании индексации и EXPLAIN могут дать совершенно неожиданные результаты.
90% - проблемы логики приложений
Согласен. Тут резонен вопрос: сколько синьоров знают (слышали хотя-бы) об книге Касьянова "Оптимизационные преобразования программ"? А ведь она пригодна и к архитектурным вопросам вполне. )
ни разу не было прецедента когда критичные проблемы оптимизации работы информационной системы были решены с помощью создания индексов
Конечно. Индексы это как гигиена. Просто должны быть.
Согласен. Но тем не менее, по личному опыту, при возникновении проблем с производительностью в проде первое, что проверяется - это именно что у нас там с БД.
при возникновении проблем с производительностью в проде первое, что проверяется - это именно что у нас там с БД
Устоявшаяся практика никогда не была равна эффективному решению и инженерному анализу.
В реальной жизни , уже скоро 6 лет как причины инцидентов операционной недоступности информационных систем неизменны:
90% - проблемы инфраструктуры (виртуализация, сеть, файловые системы в read only и т.п.)
9% - проблемы приложения, потому никто никогда не проводит нагрузочных и стресс тестов.
1% - массовые вставки данных, не успели расширить файловые системы.
СУБД как причина инцидента - никогда не было.
Почему "первое, что проверяется - это именно что у нас там с БД" ? У нас кстати, тоже именно так - чуть, что сразу в отдел администрирования баз данных обращаются - "ой у нас тут что-то форма долго загружается "
Просто инженеры DBA более отзывчивые и обладают более широким взглядом на инфраструктуру в целом. Инженер DBA может посмотреть что-там по vmstat или itop , а инженер Unix запускать простейший select .... from pg_stat_activity вряд ли будет.
Куда же исчезает текст? Одни сплошные списки, списки...
Кругом не эффективность, нет, а только риски, риски, риски...
Оптимизация производительности приложений: проблемы, решения, практические рекомендации