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

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

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

Проблемы настройки конфигурации аппаратного обеспечения

Изложенное в этом разделе может на первый взгляд показаться тривиальным, тем не менее, автор обязан остановиться на всех этих вопросах для полноты изложения.

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

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

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

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

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

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

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

Будут ли операции, проводимые в системе, создавать нагрузку, влияющую в основном на процессор или на систему ввода-вывода? (Что касается баз данных, то почти во всех случаях наблюдается последний вариант, но есть и исключения.)

Предусматривается ли эксплуатация больше чем одной производственной базы данных? Если ответ на этот вопрос является положительным, то будут ли различные эксплуатируемые базы данных относиться к разным типам (OLTP и OLAP)?

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

Чем измеряются риски останова системы?

Чем измеряются риски потери данных?

Является ли производительность наиболее значимым фактором?

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

Следует отметить, что и в этом разделе изложены лишь самые основные вопросы, но приведенный здесь материал вполне позволяет сразу же приступить к делу. А ниже приведены некоторые более подробные сведения по рассматриваемой теме.

Монопольная эксплуатация сервера

Очевидно, что лучше всего предусмотреть отдельный компьютер исключительно для эксплуатации СУБД SQL Server, а все прочие приложения установить на отдельном компьютере (компьютерах). Но следует отметить, что это правило не всегда соблюдается.

Если под управлением СУБД эксплуатируется относительно небольшое и простое приложение, которое применяется вместе с некоторыми другими подсистемами (допустим, в нем в качестве Web-сервера используется сервер IIS), то фактически в целях повышения производительности более оправданным яв.1яется решение разместить все компоненты системы на одном компьютере. Рассмотрим, с чем это связа-

но. Дело в том, что иногда между двумя подсистемами передаются большие объемы данных (например, если база данных, эксплуатируемая под управлением СУБД SQL Server, применяется для создания Web-страниц); в таком случае при эксплуатации СУБД SQL Server и Web-сервера на одном компьютере обмен данными происходит через оперативную память, поэтому исключается такое потенциально узкое звено передачи данных, как локальная сеть. Ведь пропускная способность сети может оказаться недостаточной даже в выделенной магистральной сети.

Но следует учитывать, что в данном случае речь идет об исключении, а не о правиле. Ниже приведены условия, при которых эксплуатация СУБД SQL Server на одном и том же компьютере вместе с другими приложениями является наиболее целесообразной.

Эксплуатируемые системы обмениваются очень большими объемами данных.

Функционирование всех систем почти полностью сводится к такому обмену данными (иными словами, почти все операции, выполняемые совместно функционирующими подсистемами, сводятся к обеспечению их взаимодействия).

Определенная часть совместно эксплуатируемых подсистем в основном потребляет рес}сы процессора, а другая часть главным образом использует ресурсы подсистемы ввода-вывода.

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

Сопоставление приложений, создающих нагрузку преимущественно на подсистему ввода-вывода или процессор

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

Если уже установленная и эксплуатируемая система показывает недостаточно высокую производительность, то для определения того, зависит ли это от аппаратных средств и недостаточно приемлемого распределения нагрузки на процессор или подсистему ввода-вывода, можно применить сочетание таких приложений, как утилита perfmon (сокращение от Performance Monitor), входящая в состав программных средств сервера Windows Server, и программа SQL Server Profiler. Нагрузка процессора может рассматриваться как слишком высокая, если она неизменно находится на уровне примерно 60%. Некоторые специалисты готовы оспаривать эту цифру, утверждая, что допустимая нагрузка может достигать 80%, но при столь высокой нагрузке процессора в работе пользователей возникают замедления, а поскольку, по мнению автора, необходимо предоставлять пользователям наиболее комфортные условия, рекомендуемое автором пороговое значение немного ниже. Что же касается нагрузки на подсистему ввода-вывода, то способность компьютера справляться с ней во многом зависит от характеристик производительности дисководов и контроллеров компьютера.