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

Максимально равномерно распределить дисковый ввод/вывод по не­скольким дисковым устройствам.

Обеспечить не менее x% незанятых ресурсов ЦПУ в часы пиковой нагрузки.

Увеличить коэффициент попаданий в кэш буферов базы данных как минимум до x%.

Исключить все полные просмотры таблиц в системе.

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

Для того чтобы выяснить, надежна ли спецификация проекта по повыше­нию производительности, задайте себе вопрос: «Можно ли выполнить требо­вания спецификации, не повысив при этом производительность системы?».

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

Прием с игрой в злого джинна применял в своих мысленных экспери­ментах Рене Декарт (Rene Descartes) в 1600-х годах, и, сравнительно недавно, героиня Элизабет Херли (Elizabeth Hurley) в фильме «Bedazz-led» (в российском прокате - «Ослепленный желаниями»). Вот как злой джинн мог бы сыграть по приведенным выше правилам:

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

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

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

И это просто: воспользуйтесь новой демонстрационной программой Коннора МакДональда (Connor McDonald), приведенной в приложе­нии C. Вы узнаете, как увеличить коэффициент попаданий в кэш буферов до любого количества девяток, загружая процессор ненуж­ной работой. Такая дополнительная нагрузка, разумеется, снизит производительность системы, зато «улучшит» коэффициент попа­даний. Конечно, программа Коннора - это трюк, демонстрирующий ошибочность представления о коэффициенте попадания, как о кри­терии качества системы. (Мне достоверно известно, что Коннор -не злой, хотя и был однажды замечен в поведении, отчасти прису­щем джинну .)

Есть и более изощренные способы снижения производительности системы при одновременном «улучшении» коэффициента попада­ний в кэш. Например, так часто поступают «настройщики» SQL, привлекаемые в проект для исключения операций полного про­смотра TABLE SCAN FULL (обсуждаемых в следующей спецификации). Еще один способ, которым злой джинн может увеличить коэффи­циент попаданий в кэш, снизив при этом производительность, за­ключается в уменьшении размера буфера для выборки массивом1 до одной строки [Millsap (2001b)]. В силу того, что можно так про­сто увеличить коэффициент попаданий в кэш буферов, снизив при этом производительность системы, данное требование следует при­знать исключительно ненадежным.

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

SCAN FULL [Millsap (2001b); (2002)]. Из-за того, что исключение пол­ного просмотра таблиц способно реально снизить производитель­ность, такое требование не может служить надежной основой для спецификации проекта по повышению производительности.

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

Ускорить работу системы.

Однако даже такая спецификация ненадежна. Я встречал десятки проектов, выполненных по такой спецификации, формально успеш­ных, но неудачных по существу. Например, консультант, исследуя V$SQL, находит пакетное задание, выполняющееся четыре часа. Он «на­страивает» его так, что оно выполняется за 30 минут. Проект реализо­ван успешно - выданное консультантами заключение подтверждает это. Однако достижение лишено смысла. Пакетное задание и так вы­полнялось с достаточной скоростью, поскольку запускалось во время свободного от других работ восьмичасового перерыва. Средства, вло­женные в повышение производительности (оплата консультантов), не принесли выгоды бизнесу.

Хуже того, я знаю аналитиков, ускорявших некую программу A ценой замедления другой, гораздо более важной, программы B. Во многих системах существуют взаимные зависимости между процессами, спо­собные привести к такому результату. В таких системах «настройка» второстепенной программы не только отнимает время и деньги на вы­полнение этих работ, она фактически снижает ценность системы для бизнеса (см. раздел «Пример 1: Заблуждения, вызванные общесистем­ными данными» в главе 12).

Спецификация «ускорить работу системы» слишком расплывчата, чтобы быть полезной. Работая в отделе обслуживания корпорации Or­acle, я неоднократно участвовал в дискуссиях, посвященных специфи­кациям проектов, - внедрение сервисных пакетов невозможно без спе­цификации целей проекта на уровне контракта. Большинство участни­ков этих совещаний очень быстро понимали, что требование «ускорить работу системы» звучит слишком неопределенно. Что меня поражает сейчас - это то, что многие из них видели неопределенность совершен­но не там, где надо.

Большинство людей видят суть проблемы в той части спецификации, которая предписывает ускорить работу системы. Они считают это тре­бование неполным, т. к. в нем отсутствует указание, насколько уско­рить. На упоминавшихся мною совещаниях в Oracle попытки конкре­тизировать такую спецификацию обычно выливались в обсуждение различных методик измерения фактической и субъективной скорости, способов введения «эквивалентных» метрик, основанных на счетчиках событий (аналогично коэффициенту попаданий), и т. д. Конечно, поис­ки «эквивалентных метрик» заканчивались ничем, потому что (если вы правильно выполните тест на злого джинна) такие метрики, основан­ные на предположениях, обычно оказываются ненадежными.

Выясняя, насколько «должна ускориться» система, зачастую удается лишь без пользы растратить ресурсы проекта. (Исключение составля­ет случай, когда аналитик находит максимально допустимое время выполнения операции путем моделирования с применением теории массового обслуживания, как показано в главе 9.) Сегодня, когда на­ши слушатели обсуждают требование по ускорению системы, их почти не приходится подталкивать к правильному решению о том, что суть проблемы скрывается в слове система. Рассмотрим, например, такие часто предлагаемые «улучшения» исходной спецификации «ускорить работу системы»:

Ускорить работу системы на 10%.

Заставить систему выполнять все бизнес-функции менее чем за 1

секунду.

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

Вы действительно уверены в том, что каждая бизнес-транзакция в системе может выполняться на 10% быстрее? Даже та, которая требует лишь пары обращений к логическому вводу/выводу (LIO) Oracle? С другой стороны, действительно ли достаточно ускорения на 10% для онлайнового запроса, если его время отклика составля­ет 17 минут?

Что хорошего в том, что время выполнения выборки единственной строки по первичному ключу составит 0,99 секунды? С другой сто­роны, разумно ли ожидать, что приложение Oracle сможет постро­ить 72-страничный отчет менее чем за одну секунду?

Привели ли эти два дополнения к улучшению исходного требования «ускорить работу системы»? Нет. Гораздо более серьезная проблема связана с недостаточно четко определенным понятием «система».

Что такое система? Большинство администраторов систем и баз дан­ных интерпретируют этот термин иначе, чем все остальные участники бизнеса. Для большинства администраторов система - это сложная совокупность процессов, областей разделяемой памяти, файлов, бло­кировок и защелок, а также разных технических штучек, доступных через «V$-таблицы», утилиты операционной системы и, возможно, графические средства системного мониторинга. Однако никто, кроме администраторов, не видит систему с этой стороны. Для пользователя система - это набор экранных форм и пакетных заданий, соответст­вующих его области деятельности. Для менеджера система - это ин­струмент повышения эффективности бизнеса. И пользователям, и менеджерам красные, желтые и зеленые индикаторы на вашей панели мониторинга абсолютно безразличны.

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

Пожалуйста, помните об этом, когда выступаете в роли аналитика по производительности: система - это набор пользовательских программ. Конечные пользователи относятся к ним очень внимательно. (Если на какую-то программу никто не обращает внимания, это означает, что ее надо запускать в нерабочее время или, возможно, не запускать во­все.) Период времени, который требуется программе для выработки очередной порции данных для бизнеса, - это ее время отклика. Время отклика отдельной пользовательской операции - это единственный показатель производительности, который представляет интерес для бизнеса. Следствие:

В первую очередь вас должно интересовать время отклика операций конеч­ного пользователя.

Избавившись от неоднозначного толкования слова «система», мы зна­чительно приблизились к правильному формулированию цели:

В интересах бизнеса необходимо увеличить производительность програм­мы A в рабочие дни с 14:00 до 15:00. В этот период производительность программы A должна быть увеличена настолько, насколько это возможно.

Но является ли эта спецификация «джинноустойчивой»? Еще нет. Допустим, среднее время выполнения программы A составляет две минуты. Предположим, злой джинн мог бы сократить время отклика с двух минут до 0,25 секунды. Великолепно... Но это обойдется в $1 000 000 000. Увы. Возможно, достаточно будет уменьшить время отклика до 0,5 секунды, затратив на это всего $2000. В приведенной спецификации не упоминаются никакие экономические ограничения.

И все же существует спецификация проекта, которая, я уверен, может устоять перед происками джинна. Это цель оптимизации, сформули­рованная Эли Голдратом (Eli Goldratt) в [Goldratt (1992), 49]:

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

Эта спецификация задает обязательные условия, которым должны со­ответствовать все прочие спецификации проектов. Однако она тоже страдает излишней обобщенностью, как и уже упоминавшееся прави­ло «забивать мяч в лунку каждым ударом».