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

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

Проект повышения производительности, реализуемый в соответствии с методом R, протекает существенно иначе, чем проект, основанный на методе C- обычном методе проб и ошибок, описанном в главе 1. Различия проиллюстрированы на рис. 3.1. Обычно исполнитель про­екта ощущает, что лед тронулся, в тот момент, когда закончены выбор целей и сбор данных и можно приступать к этапу анализа и проверок. Как правило, исполнитель, действующий по методу C, достигает этого момента (момент t1 на рис. 3.1) раньше, чем тот, кто работает над той же проблемой по методу R (момент t2). Если вы не ожидали такого по­ворота событий, то метод R может стать политически уязвимым.

В промежутке между моментами t1 и t2 риск потери сторонников ново­го метода максимален.

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

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

Последний изъян метода C связан с тем, что он практически не позво­ляет количественно оценить момент «окончания настройки». Во мно­гих проектах пользователи метода C не в состоянии обоснованно су­дить о действительном вкладе каждого обнаруженного источника в возникновение проблемы. Даже в «успешных» проектах исполните­ли в течение недель и даже месяцев не имели представления о том, достигнуто ли полное решение проблемы производительности (опти­мизация) или лишь частичное (настройка). Проблема неопределенно­сти в вопросе о том, возможно ли дальнейшее улучшение выполнения пользовательской операции, приводит к состоянию, которое Гаджа Вайдьянатха (Gaja Vaidyanatha) и Кирти Дешпанде (Kirti Deshpande) остроумно назвали «маниакально-настроечным расстройством» (Com­pulsive Tuning Disorder - CTD) [Vaidyanatha and Deshpande (2001) 8]. В продолжение их шутки могу добавить, что CTD - это болезненное со­стояние, вызванное надеждой. Если быть более точным, к состоянию CTD приводит отсутствие полной информации, позволяющей обосно­ванно судить о возможности дальнейшего повышения производитель­ности некоторой пользовательской операции. Метод R заполняет этот

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

Создавая метод R, мы пришли к необходимости предварительного полу­чения легкодоступных диагностических данных, позволяющих принять решение о необходимости сбора дополнительных, более труднодоступ­ных данных. Мы сочли такой подход близким к оптимальному. Его не­достаток в том, что практически нельзя быть уверенным в наличии при­чинно-следственной связи, не имея корректных диагностических дан­ных (разумеется, получить корректные данные не всегда просто). Эле­менты сомнения и неопределенности, привносимые в проект анализом легкодоступных данных, приводят к быстрой его деградации. Я неодно­кратно наблюдал, как некачественные диагностические данные заводят аналитика в тупик. В связи с этим уместно вспомнить замечательное вы­сказывание, приписываемое кардиналу Томасу Вулси (Thomas Wolsey) (1471-1530): «Будьте весьма и весьма осторожны, вкладывая что-то себе в голову, потому что уже никогда не сможете вынуть это обратно».

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

Для того, кто впервые применяет метод R, получение диагностических данных может стать самой сложной частью проекта. Есть приложения, в которых сбор диагностических данных чрезвычайно прост. Другие превращают получение корректных диагностических данных в тяже­лое испытание. В главе 6 рассмотрены простые и сложные типы прило­жений и показаны приемы, помогающие мне и моим коллегам преодо­левать различные трудности. Хорошая новость: как только вы пойме­те, каким способом следует получать правильные диагностические дан­ные для выбранной пользовательской операции, работа в следующих проектах пойдет значительно легче и быстрее. Ну а метод C так никогда и не избавится от многочисленных итераций анализа/проверки, на количество которых не влияет уровень квалификации аналитика.

Надеюсь, в будущем большинство производителей прикладного ПО об­легчат пользователям и аналитикам сбор точных диагностических данных, необходимых методу R. В последних версиях Oracle E-Busi­ness Suite процесс диагностики упрощен, и, судя по дошедшим до ме­ня сведениям, в 10-й версии Oracle ядро и сервер приложений двига­ются в том же направлении. Методы, аналогичные методу R, домини­руют в других областях промышленности, и прогресс в области сбора диагностических данных приведет к повсеместному его признанию как основы проектов повышения производительности.