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

Идеал и реальность

Когда я размышляю о проблеме компьютерной производительности, мне часто приходит в голову сравнение с вторичным рынком принадлежностей для автомобилей. Сотни поставщиков предлагают продукты, увеличивающие мощность автомобиля, но при этом если применение продукта A обеспечивает увеличение мощности двигателя на 25 л. с., а продукта B - на 15 л. с., то при использовании обоих продуктов выигрыш не суммируется; другими словами, мощность мотора не увеличится на 40 л. с. Обычный автомобиль отличается от идеальной тестовой модели, используемой поставщиками, и счастлив тот автолюбитель, который получит общий выигрыш, равный заявленному показателю одного из продуктов. Как и автомобильные компании, компьютерные поставщики составляют тесты, чтобы представить свои продукты в самом выгодном свете.

Но реальные сети - не идеальная среда, в которой так легко заменить слабое звено, чтобы повысить производительность. Известно такое высказывание: «Целое - это больше, чем сумма составных частей». Проблемы производительности, которые приходится решать системному администратору, часто симптоматичны; сетевая среда испытывает неизвестные влияния, которые выражаются в снижении производительности. Пользователи могут жаловаться на «медленную» сеть. Это симптом. А как выяснить причину «заболевания»?

Несколько лет назад я беседовал с директором по информационному обеспечению компании из списка Fortune 50. Его офис, расположенный в корпоративной штаб-квартире, одновременно был отделом ИТ в сравнительно небольшом по числу сотрудников головном офисе корпорации (на четырех этажах здания компании работает около 300 служащих). Отдел ИТ был готов сломать существующую сетевую инфраструктуру и заменить ее самой скоростной сетевой технологией. Из рассказа директора я заключил, что замена всего оборудования проблемы не решит. Поэтому пришлось собрать более подробную информацию. Выяснилось, что все 300 пользователей головного офиса были подключены к одному сетевому сегменту. Я предложил сегментировать сеть по этажам и установить между этажами более скоростную магистраль. Через две недели я получил по электронной почте благодарственное письмо. В нем говорилось, что я сэкономил компании 250 000 долларов. Мне было легко справиться с этой задачей, но сотрудникам отдела ИТ она казалась неразрешимой, так как их взгляд был ограничен узкой зоной ответственности, а внимание сосредоточено исключительно на симптомах в этой зоне. Мое преимущество состояло в том, что, взглянув со стороны, я мог увидеть проблему в целом.

Анализируй дважды

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

Первая ошибка - инженеры не понимают особенностей бизнес-процесса и той роли, которую может играть небольшое, но важное подразделение: «Сегодня мы развертываем все согласно плану, но что делать с 25 художниками с их Mac?» Вторая ошибка - незнание существующей сетевой инфраструктуры: «Почему меня не предупредили, что наше соединение с Internet - всего лишь дробное T1? Мы пытаемся проталкивать данные сотен пользователей по очень медленным каналам».

Необходимо разработать хороший аналитический процесс для поиска причин недостаточно высокой производительности в конкретной среде. Всегда существуют проблемы, которые решаются легко (например, путем замены оборудования). В случае снижения производительности после программной модернизации иногда достаточно просто расширить память пользовательских компьютеров, не заменяя аппаратные средства. Но сначала необходимо убедиться, что устраняется именно причина неполадок, а не симптомы. Даже если администратор уверен, что пользователю нужна новая и более быстрая машина, с модернизацией торопиться не следует. Как повлияет на остальную сеть замена машин Pentium II с частотой 233 МГц на Pentium IV с частотой 2 ГГц? Ком-пьютеры с Pentium IV будут полезны, если причиной перегрузки сети было слишком длительное время обработки данных машинами Pentium II. Не стоит поддаваться соблазну решить проблему с помощью новой-лучшей-быстрой-мощной техники, предварительно не проанализировав ситуацию. Устранив причину, можно избежать повторения симптомов; устранив симптомы, мы лишь временно прячем проблему, а когда она проявится снова, справиться с ней будет гораздо труднее.

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

Дэвид Черников - старший редактор Windows & .NET Magazine и главный технолог компании Ripple Technologies. С ним можно связаться по адресу: david@winnetmag.com.