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

Оптимальной производительности можно достичь, лишь объединив безупречный проект с мощными аппаратными средствами и верно выбранной конфигурацией. Пример из практики: клиент пригласил консультанта для проектирования приложения, работающего на Microsoft Internet Information Server (IIS) 4.0 и Microsoft SQL Server 6.5, для своей корпоративной сети. Программа работала медленно, и клиент был недоволен. Консультант утверждал, что причина медлительности приложения – в нехватке аппаратных ресурсов. Тогда клиент заменил сервер базы данных на более быстродействующий сервер, расширил память и установил в сервере приложений более быстрый жесткий диск. Однако скорость приложения увеличилась незначительно. В действительности существовало несколько проблем, но причина была не в аппаратных средствах. Низкая производительность была связана в первую очередь с ошибками при проектировании и разработке. Приложение с пользовательским интерфейсом на базе документов ActiveX медленно загружалось на клиентские машины и потребляло больше вычислительных ресурсов, чем программы HTML. Использование немногочисленных индексов базы данных не давало нужного результата. Из-за ошибок на этапе программирования построение древовидной управляющей структуры в сетевом приложении занимало 20 с. Лишь незначительная часть вычислений выполнялась на сервере, и приложение клиента не могло распределить нагрузку между серверами, так как для этого требуется, чтобы все запросы пользователя поступали на один и тот же Web-сервер. Приложение нуждалось в существенной переработке.

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

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

Первые и самые общие решения на этапе проектирования в значительной мере определяют рабочие характеристики продукта. Системные администраторы и другие члены группы должны быть готовы представить свои предложения по аппаратным средствам, операционной системе (Windows NT или 2000) и инструментарию для реализации приложения – Visual Basic (VB) в сочетании с Active Server Pages (ASP) или Visual C++ (VC++) и Internet Server API (ISAPI).

Приложив некоторые усилия, можно выяснить, каким образом различные факторы влияют на производительность. Например, в 1999 г. специалисты компании Doculabs измерили производительность эталонного Web-серверного приложения для гипотетического электронного книжного магазина с названием Nile. Одна версия программы была составлена с использованием VB и ASP, а другая – VC++ и ISAPI. Затем приложения были протестированы на четырехпроцессорных серверах Compaq ProLiant 6400 в среде NT 4.0 и IIS 4.0. В 2000 г. разработчики Microsoft провели аналогичные тесты на восьмипроцессорных серверах Compaq ProLiant 8500, работающих под управлением Windows 2000 Advanced Server (AS) и Internet Information Services (IIS) 5.0. Результаты обоих тестов показаны на Диаграмме 1, из которой видно, насколько сильно производительность зависит от платформы и инструментария проектирования.

Последующие тесты приложений NT, проведенные Microsoft на новой аппаратуре, показали, что при переходе на Windows 2000 результаты улучшаются приблизительно на 30%. В отчете по этим тестам, «Architecture Decisions for Dynamic Web Applications: Perfor-mance, Scalability, and Reliability», приведена более подробная информация и даются полезные рекомендации по повышению производительности. Отчет можно найти по адресу: http://msdn.microsoft.com/library/rechart/docu2kbench.htm.

Чтобы обеспечить необходимый уровень производительности, системные администраторы должны реализовать инфраструктуру для функционирования промежуточных и рабочих серверов, а также серверов для разработки и тестирования. Я рекомендую схему, показанную на Рисунке 1. Каждый сервер или группу серверов, которым назначена особая функция, следует соответствующим образом настроить.

Сервер разработки – это сервер, используемый группой программистов для проектирования и создания приложений. Обычно разработчики обращаются с ним бесцеремонно и устанавливают на нем программные продукты нескольких типов. Я рекомендую использовать на сервере разработки пакет управления версиями исходного кода (например, Microsoft Vusual SourceSafe), связав его с контрольной базой данных исходного текста.

Использование отдельных серверов для разработки и тестирования – оптимальный подход, придерживаться которого необходимо как системным администраторам, так и программистам. Между тестовыми и рабочими серверами должно быть как можно меньше различий. Тестовые серверы используются на двух этапах цикла проектирования. На первом этапе проводится тестирование прототипов программ. Это позволяет определить, как выбранные технологии будут вести себя в рабочей среде: например, как ведет себя интерфейс на базе документов ActiveX, построенных с помощью VB, по сравнению с интерфейсом на основе HTML. Следует убедиться, что при тестировании прототипов используются базы данных, типы данных и объем которых соответствуют характеристикам рабочей среды. Закончив испытания, программисты могут вернуться к серверу разработки для того, чтобы отладить детали.

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

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

Последний компонент серверной схемы – рабочий сервер. Его следует использовать только для производственных целей. Не нужно обременять рабочий сервер базой данных, функциями управления документами и другими приложениями. Чтобы добиться оптимальной производительности IIS, необходимо специально настроить рабочий сервер на выполнение приложений Web-сервера.

Файлы многих Web-приложений хранятся на совместно используемом жестком диске рабочей станции или на сервере. Машины IIS подключаются к этому жесткому диску или серверу через сеть. Если требования к производительности приложения особенно высоки, то его разделяемые файлы следует скопировать на локальный диск Web-сервера так, чтобы серверы могли получать доступ к файлам на жестком диске через системную шину. Необходим быстрый жесткий диск, и не следует заполнять его более чем наполовину (по мере заполнения дисков информацией скорость их работы снижается). Для повышения производительности жесткие диски нужно чаще дефрагментировать. В качестве быстродействующего хранилища можно использовать и устройства типа Storage Area Network (SAN), подключенные по волоконно-оптическому каналу.

Особые требования предъявляются к аппаратным средствам серверов баз данных, используемых Web-приложениями; имеет значение и физическая конфигурация сервера базы данных. Следует использовать отдельные места хранения данных (например, несколько дисковых контроллеров, подключенных к собственной системе RAID) для данных приложений и журналов. Отдельные контроллеры обеспечивают раздельные пути доступа к данным каждого набора жестких дисков. Серверы баз данных выигрывают от применения нескольких процессоров; обычно они требуют памяти больше, чем Web-серверы. Если серверы базы данных объединены в кластер, то подключать разделяемые жесткие диски следует по быстрому волоконно-оптическому каналу.

В высокопроизводительных системах рекомендуется применить какой-нибудь метод равномерного распределения сетевой нагрузки. Специалисты Microsoft протестировали с приложением Nile службу Windows 2000 Net-work Load Balancing (NLB). Выяснилось, что максимальная пропускная способность двух Web-серверов, объединенных в пул с наличием механизма балансировки нагрузки, превышает производительность одного сервера почти на 100%. Этот результат значительно превосходит выигрыш от установки в машину второго процессора. Кроме того, пул Web-серверов гораздо надежнее многопроцессорной системы: в случае отказа одного из серверов пула второй компьютер сохраняет работоспособность.

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

Чтобы повысить стабильность IIS, рекомендуется выполнять приложения с изолированными процессами в памяти. Однако в режиме изоляции процессов значительно снижается скорость выполнения приложений (хотя Windows 2000 работает с изолированными процессами лучше, чем NT). Чтобы определить, применяются ли приложением изолированные процессы, нужно выяснить, есть ли в нем компоненты COM+. Если в программе используются компоненты COM+, следует обратиться к Internet Service Manager (ISM) и открыть окно Default Web Site Properties. Убедитесь, что параметру Application Protection на закладке Home Directory присвоено значение Low (IIS Process), как показано на Экране 1. В режиме Low все процессы выполняются в пространстве процессов IIS, и достигается максимальная производительность. Недостаток этого режима заключается в том, что сбой компонента может привести к отказу IIS.

Если параметру Application Protection ранее имевшему значение Medium или High требуется задать значение Low, то для приложения необходимо изменить и параметр Activation type. Следует открыть Component Services Explorer, щелкнуть правой кнопкой на приложении, параметры которого требуется изменить, выбрать пункт Properties и щелкнуть на закладке Activation. Принимаемый по умолчанию тип Activation type – Server application. Если, как показано на Экране 2, выбран тип Library application, то приложение запускается как внутренний процесс, а на экран выводится сообщение о необходимости изменения свойств приложения. Однако в сообщении не указывается, какие именно свойства следует изменить, поэтому придется проверить все параметры приложения.

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

COM+ и IIS 5.0 тесно связаны между собой, и каждый COM-компонент, используемый ASP-приложением для IIS 5.0, увеличивает издержки и замедляет скорость работы приложения. Программисты и системные администраторы должны совместно проанализировать каждое приложение COM+ и настроить свойства COM+ в соответствии с потребностями Web-приложения. Например, с помощью COM+ разработчики могут автоматизировать обработку транзакций; однако к настройке данной функции нужно подходить обдуманно. Использование транзакций оправдано лишь при явной необходимости. Кроме того, в соответствующем приложении COM+ следует отключить лишние функции с помощью Com-ponent Services Explorer. Например, если компоненты транзакции не используют, то нет необходимости в сборе информации о событиях, синхронизации, транзакциях и JIT-активизации.

Не изучив реестр, трудно определить, имеются ли в приложении компоненты COM+. Следует отыскать в ASP-сценарии строку Server.CreateObject и узнать у программистов, используются ли программой компоненты COM. Нужно иметь в виду, что в приложениях ASP, VB и VC++ могут применяться компоненты из нескольких приложений COM+.

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

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

Благодаря применяемой в ASP функции буферизации, уменьшается число команд вывода, передаваемых IIS в выходной поток, и повышается производительность Web-сервера. Если в ASP-приложении включена функция буферизации, то перед пересылкой каждая страница будет построена полностью. По умолчанию, функция буферизации активизирована в IIS 5.0, но отключена в версии 4.0.

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

Чтобы включить функцию буферизации, нужно открыть в ISM страницу Web Site Properties, выбрать Home Directory или Directory (для виртуального каталога) и щелкнуть на кнопке Configuration, чтобы открыть страницы Applicaton Configuration. Щелкнув на закладке App Options, следует выбрать пункт Enable buffering. Действие буфера обычно не отражается на работоспособности программы, но тем не менее, после внесения изменений, приложение необходимо протестировать.

В процессе тестирования приложения разработчики могут установить и отладочные параметры ASP. Если этот режим активизирован, то производительность программы резко снижается. Чтобы проверить отладочные параметры, следует открыть страницы Applica-ton Configuration, как при активизации буфера. Открыв страницу App Debug-ging, нужно убедиться, что оба флажка в разделе Debugging Flags сняты.

Система аудита Windows 2000 и NT – важнейший инструмент безопасности. Тем не менее излишнее увлечение аудитом – один из верных способов снизить производительность до неприемлемого уровня. Я видел много серверов, отказавших из-за этой ошибки. План безопасности должен состоять из практичных правил аудита. Не следует проверять каждое действие с каждым объектом на Web-сервере. Нельзя забывать, что с увеличением числа проверок растет и объем непроизводительной работы сервера.

COM+ обеспечивает дополнительный уровень безопасности на прикладном уровне. Программисты могут даже наделить компоненты COM+ встроенными функциями защиты. Но чем шире в приложении используются функции безопасности COM+, тем медленнее работает программа. В большинстве приложений защита реализуется в программном коде ASP и/или в базе данных, а функции безопасности COM+ не применяются. Если приложение надежно защищено и без COM+, то следует открыть Component Services и отключить функции безопасности приложения.

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

Важно продумать процедуры для дальнейшей настройки приложения и сервера после сдачи программы в эксплуатацию. Тестовая нагрузка на приложение должна быть близкой к реальной; в этом администратору помогут такие продукты, как Microsoft Web Application Stress, и другие инструменты производства независимых компаний. В процессе тестирования следует отмечать узкие места и просить программистов вносить изменения в исходный текст, стараясь поднять производительность на более высокий уровень. Затем необходимо провести повторное тестирование. Каждое изменение и его результаты должны документироваться. Тестирование и настройка покажут, как каждое сделанное изменение – проекта, аппаратных средств или конфигурации – влияет на производительность. Эти сведения – ключ к поддержанию максимальной производительности IIS.

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