Хотя люди в большинстве своем способны интуитивно понять формат профиля ресурсов, несколько формальных правил все же помогают бо­лее эффективно использовать представленную в нем информацию. Мы с коллегами, проанализировав, начиная с 2000 г., несколько сотен профилей ресурсов, обобщили наш подход в следующих основных пра­вилах:

Работайте с данными профиля ресурсов в порядке убывания вклада в общее время отклика.

Исключите лишние вызовы, прежде чем пытаться уменьшить за­держку на каждый вызов.

Если после исключения избыточных обращений к ресурсу его вклад во время отклика все еще слишком велик, избавьтесь от не­нужной конкуренции за этот ресурс.

М ой друг и коллега по издательству O'Reilly Дэйв Энсор (Dave Ensor) в своих публичных выступлениях отмечает, что существуют три подхо­да к решению проблемы времени отклика, вызванной дефицитом неко­торого ресурса:

Коммерческий подход заключается в увеличении ресурса. Такой подход действительно улучшает показатели чистой прибыли, воз­врата инвестиций и движения денежных потоков. К сожалению, эти улучшения имеют место для ваших поставщиков, но... не для вас.

Исследовательский подход заключается в манипуляциях с конфи­гурациями, параметрами, оборудованием и всем тем, что может за счет «настроек» хоть как-то уменьшить время обработки запросов. При действительно больших задержках выполнения вызовов техни­ческие специалисты испытывают непреодолимое желание что-ни­будь «настроить». Такая разновидность настройки - Самое Любимое Развлечение для исследователя, живущего в каждом из нас. Самое приятное здесь то, что это позволяет нам выглядеть очень занятыми людьми и избегать множества других менее интересных дел. К сожа­лению, такой подход ведет лишь к пустой трате времени при отсутствии сколько-нибудь заметного результата. Главным критерием ос­тается закон Амдала.

Разумный подход заключается в уменьшении количества обраще­ний к ресурсу. Вопрос только в том, как это сделать.

Те, кто встречался с Дэйвом или слушал его выступления, поймут, по­чему я восхищаюсь сдержанностью, которую он проявил, давая назва­ния этим трем подходам.

• Только исключив избыточные обращения к ресурсу и неоправдан­ную конкуренцию за него, можно рассматривать вопрос об увеличе­нии этого ресурса.

Эти правила постоянно помогают нам в быстрой и эффективной опти­мизации. В следующих разделах они рассмотрены более подробно.

Работа в порядке убывания времени отклика

Очень легко работать с профилем ресурсов, отсортированным по убыва­нию вклада составляющих во время отклика. Список просматривается сверху вниз. Самый первый потребитель времени отклика и есть тот ре­сурс, от которого в наибольшей степени зависит повышение производительности. Вспомните закон Амдала: чем ниже компонент расположен в списке, тем слабее его вклад в уменьшение времени отклика в целом.

В примере 10.2 приведен профиль ресурсов, построенный для опреде­ленной пользовательской операции в системе с «очевидной проблемой дискового ввода/вывода». Задержка ввода/вывода одного блока в этой подсистеме временами превышает 0,600 секунды. Большинство инже­неров сочтут задержку более 0,010 секунды на один блок неприемле­мой. А задержки в этой системе в шестьдесят раз хуже этого порого­вого значения.

Однако профиль ресурсов этой пользовательской операции ясно пока­зывает, что улучшение времени отклика для нее надо начинать вовсе не с решения проблемы дискового ввода/вывода. Единственные ком­поненты времени отклика, на которые повлияет повышение производительности ввода/вывода - это db file sequential read и db file scat­tered read. Даже если удастся полностью исключить их из профиля ре­сурсов, это уменьшит время отклика примерно на 14%.

Занятно, что «проблема» подсистемы ввода/вывода действи­тельно сказывается на производительности программы из при­мера 10.2. Данные трассировки свидетельствуют о том, что от­дельные вызовы ввода/вывода для одного блока в данной поль­зовательской операции занимают до 0,620 секунды. Но даже эта информация несущественна. Возможный выигрыш от устране­ния любых проблем ввода/вывода для данной операции столь незначителен, что лучше потратить время, требуемое на анализ и устранение проблемы, на что-нибудь другое.

Почему правильный выбор так важен

Настало время проверить, насколько вы привержены методу R. Вы мо­жете сказать: «Но ведь устранение такой серьезной проблемы ввода/вы­вода, безусловно, приведет к некоторому улучшению производительно­сти системы...». Да, действительно, решение этой проблемы даст неко­торое улучшение производительности. Но необходимо понимать, что решение этой проблемы ввода/вывода не даст ощутимого улучшения данной пользовательской операции (той, которая соответствует профи­лю ресурсов из примера 10.2 и ускорение которой отчаянно требуется бизнесу). Понимать это жизненно необходимо по двум причинам:

Время и материалы, израсходованные на решение «проблемы вво­да/вывода», - это ресурсы, которые уже нельзя вложить в повыше­ние производительности пользовательской операции, представлен­ной в примере 10.2. Если пользовательская операция выбрана пра­вильно, то отвлечение на проблему ввода/вывода, по меньшей ме­ре, непродуктивно.

Решение проблемы ввода/вывода может в действительности ухуд­шить производительность пользовательской операции из приме­ра 10.2. Это не только теоретическая возможность, мы встречались с этим явлением на практике (см. главу 12). Вот один из возможных случаев: представьте себе, что одновременно с операцией из приме­ра 10.2 в системе выполняются еще несколько программ. И эти про­граммы потребляют очень много процессорного времени, но в данное время они часто простаивают в очереди к медленному диску. Исключение задержки в очереди к диску для этих медленных про­цессов фактически приведет к обострению конкуренции за исполь­зование процессора, а это как раз та составляющая, которая преоб­ладает во времени отклика рассматриваемой операции. Таким об­разом, решение проблемы ввода/вывода на самом деле ухудшит производительность выбранной пользовательской операции.

Да, решение проблемы ввода/вывода даст некоторый прирост про­изводительности остальных программ. Но если выбор пользова­тельской операции для повышения производительности в приме­ре 10.2 сделан правильно, то улучшение производительности вто­ростепенных операций будет достигнуто ценой ее ухудшения для наиболее важной операции. Такой результат противоречит приори­тетам бизнеса.

По обеим причинам, если выбор пользовательской операции из приме­ра 10.2 сделан правильно, работа над «проблемой ввода/вывода» будет ошибкой. Если же пользовательская операция для повышения произ­водительности выбрана неверно, то это значит, что вы ошиблись при выполнении действий, описанных в главе 2.