Миллсап про тюнинг

[egorius]

Меня до сих пор удивляет то, что на рынке Oracle производительность считается работой администраторов, а не разработчиков. От разработчиков как минимум на 90% зависит, насколько быстро сможет работать приложение. Я думаю, так повелось с тех времён, когда множество проектов имело команды администраторов, но не имело команд профессиональных разработчиков.

Большинство тех проектов были связаны с внедрением больших «коробочных» приложений типа Oracle Financial и Manufacturing Applications (которые выросли в Oracle E-Business Suite). Разработчики, участвовавшие в таких проектах, не были профессионалами. Как правило, это были люди от бизнеса, не имевшие программистского образования, но им сказали, что теперь-де каждый может написать программу на этом новом языке четвёртого поколения, именуемом SQL.

Ясное дело, что внедряя Чрезвычайно Гибкое Приложение с двадцатью тысячами таблиц в базе, вы столкнётесь с проблемами производительности. Кто-то должен их решать, и администраторы оказались единственными технически подкованными людьми, способными на это. Они также участвовали в организации первых конференций Oracle, и я думаю, что с тех пор термин «performance tuning» стал прочно ассоциироваться с администраторами.

В результате по сей день встречается убеждение, что решение проблем производительности сводится к списку хитрых трюков, которые можно попробовать в надежде, что система начнёт работать чуточку быстрее. Слово «тюнинг» говорит само за себя. Я практически никогда его не использую, кроме как в насмешку, потому что это всего лишь дешёвая имитация того, что действительно нужно, а именно — настоящей оптимизации производительности, которая является задачей дизайнеров и разработчиков.

Довольно свободный перевод кусочка из оригинала.

Comments

[autoench.livejournal.com]

администраторы оказались единственными технически подкованными людьми, способными на это
Ну так, пардон, нефиг было городить монструозность на голом месте. Вот теперь расхлебывайте %)

[egorius.livejournal.com]

Дык, расхлёбываем :)
Но.
Во-первых, монструозность проистекает не из голого места, а из Чрезвычайной Гибкости. Понятно, что если тот же Oracle E-Business Suite писать каждый раз отдельно под нужды конкретной организации, то всё будет существенно проще. Но кто ж будет этим заниматься?
А во-вторых, проблемы производительности проистекают не только из монструозности приложения, но и (в основном) из больших объёмов данных. Так что проблемы гарантированы в любом случае...

[autoench.livejournal.com]

Увы, так и есть. Но, повторюсь, Оракл умышленно сдвинул центр тяжести в область администрирования. С этим вы согласны?

[egorius.livejournal.com]

Да я бы не сказал.
Традиционно-ориентированные разработчики привыкли к императивному стилю программирования. Сам всё запрограммировал, сам расхлёбываешь. Собственно, что повсеместно и происходит: попытки навязать БД своё видение алгоритма редко бывает удачным, потому что мыслить циклами при работе с БД нельзя.
А вот SQL — штука декларативная, там изрядная часть работы происходит за кулисами оптимизатора. И разработчик должен учиться не мешать оптимизатору, и даже наоборот — помогать. То есть переключиться в декларативную парадигму. И администратор тут совершенно ни при чём.
Другое дело, что оптимизатор иной раз не справляется, и чтобы разобраться в проблеме и аккуратно её исправить, требуются знания, которые к традиционному программированию отношения вроде как не имеют: все эти трассировки, ожидания, планы запроса... Считать ли это областью ответственности администратора? На мой взгляд, тоже нет.

[n1919.livejournal.com]

если копнуть еще глубже, то окажется что
производительность зависит даже от постановщиков задач

[egorius.livejournal.com]

Запросто.
Поэтому я не верю в распространенную схему (эксплуатируемую, в частности, самим Ораклом), когда разработчик понимается как тупой кодер, послушно переводящий детальное ТЗ на язык программирования.
Мы у себя так не поступаем.

[zlobny-reader.livejournal.com]

В идеале, над производительностью нужно еще раньше думать, чтобы в ТЗ были разумные требования по производительности.
Я вот как-то погорячилась и согласилась прописать, что время реакции должно быть 5-10 сек. А при каких условиях - не прописали. Дык до сих пор мучаемся.

[loveyoupeople.livejournal.com]

+1
но администраторы тоже хотят есть
но и разработчики многого не знают)

[egorius.livejournal.com]

Но администраторам и без этого работы хватает.
Но и разработчики люди неглупые, могут научиться.
Сплошные но :)

[zlobny-reader.livejournal.com]

Видимо для того, чтобы у разработчика была возможность эффективно решать проблемы производительности (в идеале - не создавать, но это мало реально), он должен обладать знаниями, которые раньше считались нужными только админам.
У нас на проекте разработчика, сходившего на 2-х недельные админские курсы, словно подменили. Удалось сдвинуть несколько проблем, казавшихся ранее тупиковыми. И еще дополнительный бонус - он начал говорить с админами заказчика на понятном им языке. Это тоже дорогого стоит.

[egorius.livejournal.com]

Интересно то, что знаниями нужно не только обладать, но и уметь их применять. Бывают примеры, когда знания есть, а толку нет :)

[nikname.livejournal.com]

Я просто в непонятках. Мне кажется, что 99% зависит от разработчиков. Есть, конеечно, проекты, в которых и тюнинг нужен и тесное взаимодействие разработчиков и спецов по конкретной БЛ, но для реально больших проектов. Ну и ту проблема в разработчиках - им всё равно, т.е. они в каком-то ваккуме обитют и не понимают,лля какой системы они пишут.

[egorius.livejournal.com]

Ну да, зависит. Если система достаточно большая, то проблема производительности рано или поздно встанет, а вот подумали ли разработчики об этом заранее? Имеют ли они необходимые знания о СУБД, или их больше привлекает какой-нибудь Объектно-Ориентированный Подход?..