Iis о настройке быстродействия


Содержание

Десять лучших способов улучшения производительности IIS 7.0

Посетителей: 11846 | Просмотров: 14496 (сегодня 2) Шрифт:

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

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

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

Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?Link >® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.

Однако основная мощность IIS 7.0 состоит не в пошаговом улучшении производительности существующих функций. Напротив, главные усовершенствования заключаются в новых возможностях, которые нужно активно использовать. Эти возможности основываются на гибкости и расширяемости новой платформы, а также на новых функциях повышения производительности. В этой статье я расскажу вам о 10 наиболее важных способах улучшения производительности, которые станут вам доступны после перехода на IIS 7.0.

Экономичные веб-серверы

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

Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!

Количество дополнительные данных от неиспользуемых модулей может быть довольно значительным — например, от модуля записи запросов в журнал или от модуля трассировки неудачно завершившихся запросов. Если удалить эти модули из окружения, где они не нужны, можно получить прирост общей пропускной способности и уменьшение времени реакции сервера, что в свою очередь улучшит такие характеристики нагрузки на сервер, как время до получения первого байта (TTFB) и время до получения последнего байта (TTLB).

На рис. 1 показаны результаты простых тестов пропускной способности для HTML-файла (статическая нагрузка) и страницы «Здравствуй, мир», написанной на ASP.NET (нагрузка ASP.NET). Использовались три конфигурации веб-сервера: с полным набором функций, с предлагаемым по умолчанию набором функций для каждого типа нагрузки и с минимальным набором необходимых для каждого типа нагрузки функций. Можно заметить, что, хотя большинство необязательных функций отключены даже в полной конфигурации сервера, пропускную способность можно существенно увеличить как в случае статической нагрузки, так и при работе ASP.NET, если полностью удалить ненужные функции.

Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.

Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

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

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

Использование экономичной операционной системы

В Windows Server ® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.

Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft ® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.

В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.

Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку

Применение топологий, адаптированных для нужд приложения

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

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

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

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

Это возможно только в конфигурации потоков IIS и ASP.NET, которая существенно влияет параллелизм и косвенно сказывается на использовании памяти, задержке и пропускной способности множества приложений. Рабочая нагрузка статического файла IIS крайне асинхронна и требует максимального уровня одновременных запросов, но использует очень небольшое количество доступных потоков. С другой стороны, многие функции ASP.NET синхронны, отличаются длительной блокировкой и требуют большого количества потоков, тогда как для других функций требуется более низкий предел параллелизма для снижения воздействия на память. Путем выделения статической нагрузки и поврежденных частей конвейера обработки процессов в отдельный процесс или сервер можно оптимизировать параллелизм каждой отдельной нагрузки.

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

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

Улучшенная поддержка приложения

Службы IIS 7.0 включают в себя расширенную поддержку платформ приложений с помощью FastCGI, открытого протокола, поддерживаемого множеством платформ приложений с открытым исходным кодом, которые в противном случае могут не поддерживать надежную и высокопроизводительную собственную интеграцию с IIS. В отличие от протокола CGI, который в течение длительного времени поддерживался IIS, FastCGI обеспечивает значительно улучшенную производительность на платформе Windows. В основном это обусловлено архитектурой многократно используемых процессов FastCGI, уменьшающей значительные затраты на создание процессов для отдельных запросов, что позволяет клиентам использовать преимущества постоянных открытых соединений.

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

Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?Link >

Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN ® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений

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

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

Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.

В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.

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

Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.

В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.

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

Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных

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

Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.

Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.

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

Можно дополнительно оптимизировать загрузку сжатия, настроив уровень сжатия для достижения необходимого соотношения сжатия и загрузки ЦП. Но на этом все не заканчивается — также можно настроить приложение для поддержки кэширования сжатого содержимого, что устраняет загрузку сжатия на попадания в кэше благодаря работе с уже сжатым содержимым. Имейте в виду, что в кэши вывода ASP.NET и IIS включена дополнительная возможность кэширования сжатого содержимого для поддерживающих это клиентов, а также обработка запросов клиентов, для которых необходимо несжатое содержимое.

Регулировка полосы пропускания для мультимедийных файлов

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

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

Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4 ) и доступный в центре загрузок iis.net (iis.net/downloads/?tab >

Рис. 4. Регулировки скорости уменьшает использование полосы пропускания

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

Кэширование выводимых данных

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

До IIS 7.0, как IIS, так и ASP.NET предоставляли возможности кэширования в форме кэша ядра IIS и кэша вывода ASP.NET. Кэш ядра IIS обеспечивал максимальную производительность, но ограничивался преимущественно статическим содержимым. Кэш вывода ASP.NET был гораздо более полным решением для кэширования динамического содержимого, за исключением более низкой производительности и менее эффективного управления памятью. Новый кэш вывода в IIS 7.0 ликвидирует разрыв между кэшем ядра IIS и кэшем вывода ASP.NET.

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

Кроме того, кэш ядра IIS 7.0 также предоставляет высокопроизводительную альтернативу кэшу вывода ASP.NET для содержимого ASP.NET, не требующего дополнительных функций кэширования (таких как зависимости кэша и недействительность данных в кэше), которые доступны только в кэше вывода ASP.NET.

Что касается кэширования выводимых данных, обычно проблемы связаны с определением верных политик срока действия содержимого, недействительности данных и изменчивости, обеспечивающих эффективное кэширование ответов и одновременное поддержание необходимой правильности и свежести кэша. В большинстве случаев это можно выполнить путем простой настройки верных правил кэширования, хотя иногда требуются более сложные политики, зависящие от информации времени выполнения. Для решения этой проблемы кэш вывода IIS 7.0 предоставляет программные API, которые могут использоваться для обеспечения необходимого поведения кэширования. Это разблокирует потенциал эффективности кэширования для содержимого, кэширование которого в противном случае было бы невыгодным. Кроме того, интегрированный конвейер ASP.NET позволяет использовать кэш вывода ASP.NET для содержимого, не относящегося к ASP.NET.

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

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

Преобразование кода ISAPI в модули IIS 7.0

В IIS 7.0 появился новый серверный интерфейс API, на котором основаны все модули IIS 7.0. Он заменяет устаревшие интерфейсы API ISAPI Filter и ISAPI Extension, использовавшиеся в предыдущих версиях IIS. Для новых модулей, которым не требуется поддержка предыдущих версий, новые API более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.

Илон Маск рекомендует:  Что такое код htmlspecialchars

Однако IIS 7.0 предоставляет возможность поддержки существующих фильтров и расширений ISAPI путем использования слоя совместимости, реализуемого посредством дополнительных модулей IIS 7.0. Это позволяет существующим компонентам ISAPI работать в IIS 7.0 без необходимости переписывания.

Хотя использование существующих вложений в ISAPI снижает планку для перехода на IIS 7.0, следует серьезно рассмотреть перенос устаревшего кода ISAPI на новые API IIS 7.0. Это устраняет затраты на слой совместимости ISAPI и позволяет использовать преимущества производительности, недоступные для компонентов ISAPI. В зависимости от работы, выполняемой компонентом ISAPI, эти преимущества производительности могут быть довольно значительными. Например, API модуля IIS 7.0 предоставляет встроенную поддержку кэширования метаданных конфигурации и других произвольных данных, связанных с узлами, приложениями, URL-адресами, что можно значительно увеличить скорость выполнения внутренних операций компонента.

Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.

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

Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера

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

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

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

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

Заключение

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

Что вы можете сделать для ускорения работы веб-сайтов IIS 7?

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

Какие еще параметры конфигурации вы можете изменить для повышения производительности? есть ли у вас «контрольный список производительности» вещей, которые нужно установить, когда вы получаете новый сервер?

Я спрашиваю об IIS 7 или более поздней версии (потому что все мои текущие серверы IIS7)

4 ответа

IIS7 + на самом деле довольно чертовски быстро. Существует не так много возможностей для ускорения IIS; в целом вы оптимизируете HTML

Советы Jesper выше — отличные рекомендации для ускорения статических веб-страниц.

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

  • Следите за своим сервером. ASP.NET публикует множество счетчиков, которые можно отслеживать в PerfMon.exe. Счетчик очереди глобального запроса покажет вам, будут ли поставлены какие-либо запросы. Это число всегда должно быть 0.
  • Оптимизировать любые вызовы внешним ресурсам, таким как базы данных и файловые системы. Длительные запросы связывают потоки и предотвращают доставку входящих запросов.
  • Если вы давно используете вызовы внешних ресурсов, подумайте о том, чтобы сделать их асинхронными. Это передает запрос в отдельный пул потоков и возвращает исходный поток в пул для обслуживания новых запросов.
  • Увеличьте размер пула потоков для более старых версий .NET. Этот параметр можно найти в файле machine.config
  • Настройте параметр веб-сада в пуле приложений IIS для использования нескольких рабочих процессов (параметр «Максимальные рабочие процессы» в расширенных настройках IIS7). Играйте с различными настройками, чтобы увидеть, что лучше всего подходит для вашей среды. Многоядерные машины смогут обрабатывать несколько рабочих процессов лучше.
  • На виртуальной машине не назначайте слишком много ядер на сервер, так как это может вызвать проблемы с размещением на вашем хосте.
  • Если вы все это пробовали и по-прежнему видите проблемы из-за нагрузки, подумайте о кластеризации вашего сервера. В Windows Server встроена балансировка сетевой нагрузки, которая позволяет настраивать небольшую веб-ферму без необходимости использования дорогостоящего балансировщика нагрузки. IIS7 также включает в себя структуру веб-фермы, которая обеспечивает то же самое, используя маршрутизацию запросов приложений (ARR). Он также обрабатывает подготовку сервера.

Быстрый веб-поиск по любому из этих вопросов вернет много хорошей информации.

Магические настройки обычно зависят от сайта. Вам нужно будет следить за тем, что происходит, чтобы найти правильные вопросы о том, что нужно изменить в IIS7.

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

Что вы можете сделать, чтобы получить гранулированную видимость доступным способом?

Джеспер Мортенсен абсолютно прав Две книги Стива являются превосходным чтением и учитывают недавнее ускорение скорости от 5,5 до 1,8 секунд ( webpagetest ) на сайте, который мы поддерживаем. Стабилизация всей системы, основанная на журналах, помогла нам обеспечить стабильную доставку по трассам и увеличить ее на пике (более 50% этого было на уровне ОС). Ничто из этого не могло быть сделано в течение 2-х дневных временных рамок без мониторинга на каждом уровне.

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

Мы внедряем модуль ARR в IIS7, поэтому мы создаем webFarm, ARR может кэшировать ваш запрос на диске и увеличивать производительность для нас, что имеет большое значение.

На странице html вы также можете использовать несколько поддоменов для своего носителя, например:

js.yourdomain.com img.yourdomain.com css.yourdomain.com

и т. д. Browser le ie, и я думаю, что другие загружают синхронные 3 соединения поддоменом.

Perpetuum informatio

Решение проблем с производительностью IIS

Иногда бывает, что на сервере IIS начинают происходить странные дела. Так например у меня возникла ситуация, в которой один из процессов w3wp.exe время от времени начинал занимать под свои вычисления весь ресурс одного из ядер (был бы одноядерный процессор было бы использование процессора на 99% или 100%). Для тех, кто не знает процесс w3wp.exe кроме всего прочего отвечает за исполнение серверного кода ASP, ASP.NET скриптов. Ясно было что, какой-то скрипт производит излишнюю нагрузку. Такое поведение для меня было неприемлимым и я постарался решить эту задачу.

Первым делом я захотел выяснить какое из используемых нами приложений производит эту дополнительную нагрузку. Для этого я попробовал вынести все приложения в отдельные виртуальные каталоги, задав для каждого отдельный пул приложений, они же Application pool (для каждого пула приложений используется отдельный процесс w3wp.exe), попутно определяя какой из процессов к какому пулу относится. Сделать это можно довольно просто при помощи утилиты Sysinternals Process explorer. Для этого достаточно зайти в свойства процесса (при этом подсказкой может служить то, что приложения написанные при помощи ASP.NET будут подсвечены жёлтой строкой), и на вкладке Image посмотреть строку Command line, из которой видно, что название пула приложений передаётся процессу w3wp.exe через параметр «ap». Так например команда запуска для пула приложений с именем «dotnet4» будет выглядеть так:

c:\windows\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmceXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -t 20 -ap «dotnet4»

Впоследствие эти действия оказались по большему счёту бесполезными, но умение определять нужный процесс w3wp оказалось впоследствии полезным и мне и нашим разработчикам выполняющим удалённую отладку в Visual Studio.

Iis о настройке быстродействия

Опубликовано: Февраль 2012 г.

Обновлено: Февраль 2012 г.

Назначение: Windows Server 2012, Windows Server 2012 R2

В этом документе описан процесс установки веб-сервера IIS и его настройки для обслуживания статического содержимого. Статическим содержимым является веб-страница (HTML), которая доставляется пользователю в том виде, в котором она хранится. И наоборот, динамическое содержимое формируется веб-приложением, таким как ASP.NET, классическим приложением ASP или приложением PHP. Статическое содержимое отображает одинаковые сведения для всех пользователей; динамическое содержимое может отображать сведения о конкретном пользователе, например имя пользователя.

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

Содержание документа

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

    Windows Server® 2012

Для установки служб IIS и работающих на их базе приложений можно использовать установщик веб-платформы. Установщик веб-платформы устанавливает последние версии доступных предложений для веб-платформы, включая обновления. Дополнительные сведения об установщике веб-платформы см. в статье Дополнительные сведения об установщике веб-платформы и его установке. Если для установки служб IIS используется установщик веб-платформы, шаг 2 можно пропустить.

Эту процедуру можно также выполнить с помощью пользовательского интерфейса Windows или командной строки.

На начальной странице щелкните плитку Диспетчер сервера, а затем нажмите кнопку ОК.

В диспетчере сервера выберите Панель мониторинга и щелкните Добавить роли и компоненты.

В мастере добавления ролей и компонентов на странице Перед началом нажмите кнопку Далее.

На странице Выбор типа установки выберите Установка ролей или компонентов и нажмите кнопку Далее.

На странице Выбор целевого сервера выберите Выбор сервера из пула серверов, выберите имя своего компьютера и нажмите кнопку Далее.

На странице Выбор ролей сервера укажите Веб-сервер (IIS) и нажмите кнопку Далее.

На странице Выбор компонентов просмотрите выбранные по умолчанию компоненты, а затем нажмите кнопку Далее.

На странице Роль веб-сервера (IIS) нажмите кнопку Далее.

На странице Выбор служб ролей просмотрите выбранные службы и нажмите кнопку Далее.

Примечание
Установите службы ролей IIS 8 по умолчанию для веб-сервера статического содержимого.

На странице Подтверждение выбранных элементов для установки подтвердите свой выбор, а затем нажмите кнопку Установить.

На странице Ход выполнения установки убедитесь, что установка роли веб-сервера (IIS) и требуемых служб ролей успешно завершена, а затем нажмите кнопку Закрыть.

Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузере следующее:


http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

На начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления.

В панели управления выберите Программы, а затем Включение и отключение компонентов Windows.

В диалоговом окне Компоненты Windows щелкните Службы IIS, а затем нажмите кнопку ОК.

Будет установлен набор компонентов IIS 8 по умолчанию. Установите только компоненты по умолчанию для веб-сервера статического содержимого.

Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузер следующее:

http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

В командную строку с повышенными привилегиями или в скрипт введите следующую команду:

Start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;IIS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

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

Откройте диспетчер служб IIS.

    При работе в Windows Server 2012 на начальной странице щелкните Диспетчер сервера, а затем нажмите кнопку ОК. В диспетчере сервера выберите меню Сервис, а затем выберите Диспетчер служб IIS.

При работе в Windows 8 на начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления. На экране Панель управления выберите Системы и безопасность, затем Администрирование, после чего выберите Диспетчер служб IIS.

На панели Соединения правой кнопкой мыши щелкните узел Сайты, а затем выберите Добавить веб-сайт.

В диалоговом окне Добавление веб-сайта в поле Имя сайта введите понятное имя веб-сайта.

Щелкните Выбрать, если нужно выбрать пул приложений, отличный от пула, указанного в поле Пул приложений. В диалоговом окне Выбор пула приложений в списке Пул приложений выберите пул приложений, а затем нажмите кнопку ОК.

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

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

В списке Тип выберите протокол для веб-сайта.

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

В поле Порт введите номер порта.

Дополнительно введите имя заголовка узла для веб-сайта в поле Заголовок узла.

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

Нажмите кнопку ОК.

В командной строке с повышенными привилегиями или в скрипте используйте следующий синтаксис:

Примечание
Чтобы этот синтаксис работал, необходимо либо находиться в следующем каталоге, либо иметь каталог в пути: %windir%\system32\inetsrv

appcmd add site /name:string /id:цел_чис_без_зн /physicalPath:строка /bindings:строка

Переменная name является именем, а переменная id — положительным целым числом, которое следует назначить сайту. Переменные name и id являются единственными переменными, которые требуются для добавления сайта с помощью команды appcmd. Но при добавлении сайта без задания значений атрибутов bindings и physicalPath сайт будет невозможно запустить.

Переменная physicalPath является абсолютным путем к содержимому сайта в файловой системе.

Переменная bindings содержит сведения, используемые для доступа к сайту. Она должна иметь вид протокол/IP_адрес:порт:заголовок_узла. Например, если указать для веб-сайта привязку http/*:85: , то это будет означать, что он прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменных имен (также известных как заголовки узлов или имена узлов). С другой стороны, привязка http/*:85: marketing.contoso.com настраивает сайт для прослушивания HTTP-запросов на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com.

Чтобы добавить веб-сайт contoso с идентификатором 2 и содержимым в папке c:\contoso, который прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com, введите в командную строку следующее:

appcmd add site /name:contoso /id:2 /physicalPath:c:\contoso /bindings:http/*:85:marketing.contoso.com

Анонимный доступ предоставляет пользователям доступ к общедоступным зонам веб-сайта без запроса имени пользователя и пароля. Анонимную проверку подлинности можно настроить с использованием учетной записи анонимного пользователя по умолчанию (IUSR) или можно настроить учетную запись локального пользователя для анонимных пользователей.

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Проверка подлинности.

На странице Проверка подлинности выберите Анонимная проверка подлинности.

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

В диалоговом окне Изменение учетных данных анонимной проверки подлинности выберите один из следующих параметров.

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

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

Важно
При использовании учетной записи IUSR анонимным пользователям предоставляется возможность с помощью этой учетной записи осуществлять доступ ко всей внутренней сети.

Нажмите кнопку ОК, чтобы закрыть диалоговое окно Изменение учетных данных анонимной проверки подлинности.

Используйте следующий синтаксис, чтобы изменить учетную запись по умолчанию для анонимного доступа:

appcmd set config /section:anonymousAuthentication /userName:строка /password:строка

Переменная username является учетной записью, используемой службами IIS для анонимного доступа, а переменная password — это пароль, который хранится в файле конфигурации по умолчанию в зашифрованном виде. Например, чтобы использовать учетную запись Moe и пароль pssword1 для анонимного доступа, в командной строке введите следующее:

appcmd set config /section:anonymousAuthentication /userName:Moe /password:pssword1

Если клиентский запрос к веб-сайту не содержит имени документа, службы IIS ищут файл, имя которого определено в качестве документа по умолчанию. Обычно именем документа по умолчанию является Default.htm. Можно определить список имен документов по умолчанию в порядке старшинства.

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Документ по умолчанию.

На панели Действия нажмите кнопку Добавить.

В поле Имя введите имя файла, которое необходимо добавить в список документов по умолчанию, затем нажмите кнопку ОК. Это имя файла будет добавлено в верхнюю часть списка документов по умолчанию.

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

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

Чтобы добавить имя файла в список документов по умолчанию, используйте следующий синтаксис:

appcmd set config /section:defaultDocument /+files.[value=’строка‘]

Переменная string является добавляемым в список именем файла. Например, чтобы добавить файл home.html в список документов по умолчанию, в командной строке введите следующее:

appcmd set config /section:defaultDocument /+files.[value=’home.html’]

Чтобы удалить файл home.html из списка документов по умолчанию, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:defaultDocument /-files.[value=’home.html’]

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

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Сжатие.

Выберите Включить сжатие статического содержимого для сжатия службами IIS статического содержимого.

В поле Статическое содержимое настройте следующие параметры:

    Выберите Сжимать только файлы размером более (в байтах) и введите минимальный размер файла, при котором файлы будут сжиматься службами IIS (необязательный шаг). Размер по умолчанию — 256 байт.

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

Кроме того, можно установить флажок Лимит места на диске на пул приложений (в МБ) и ввести максимальный размер дискового пространства (в мегабайтах), отводимого для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Например, если существует 20 пулов приложений на сервере и параметр Лимит места на диске равен 100, максимальный объем дискового пространства будет равен 2 ГБ. Если выбрать параметр Лимит места на диске на пул приложений (в МБ) и ввести в текстовом поле определенное значение, то при достижении порогового значения службы IIS автоматически очистят временную папку в соответствии с правилом удаления наиболее давно использовавшихся файлов. Значение по умолчанию — 100 МБ для каждого пула приложений.

Нажмите кнопку Применить на панели Действия.

Чтобы включить сжатие HTTP статического содержимого, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:urlCompression /doStaticCompression:True

Чтобы настроить параметры сжатия статического содержимого, используйте следующий синтаксис:

appcmd set config /section:urlCompression /minFileSizeforComp:цел_чис /directory:строка /maxDiskSpace:цел_чис

Переменная minFileSizeforComp служит для задания минимального размера файла в байтах, подлежащего сжатию. Значение по умолчанию — 256. Переменная directory служит для указания каталога, где временно сохраняются и кэшируются сжатые версии статических файлов. По умолчанию используется следующая папка:

%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Переменная maxDiskSpace служит для определения максимального количества места на диске (в мегабайтах) для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Значение по умолчанию — 100 МБ для каждого пула приложений.

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

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

Для повышения защищенности веб-сервера настройте фильтрацию запросов. Инструкции см. в статье Настройка фильтрации запросов в IIS.

Выжать максимум: тонкая настройка производительности серверных версий Windows

Содержание статьи

Win2k3 и Win2k8 по умолчанию оптимизированы под стандартную сетевую среду. Но
если серверную ОС надлежащим образом настроить (например, под требования
компании), то это благоприятно отразится на каждом аспекте работы сети, начиная
от самого оборудования и заканчивая пользователями, подключенными к серверу.

Анализируем причину

Любая внештатная ситуация, в том числе и снижение производительности сервера,
требует тщательного анализа. Не собрав всей информации, можно нагородить дел.
Возьмем такой случай. Контроллер домена (КД) уже не справляется со своими
обязанностями — пользователи подолгу регистрируются в системе или не могут зайти
в сетевую папку. В зависимости от топологии Сети, вариантов решения может быть
несколько.

Например, можно модернизировать железо, перераспределить нагрузку между
серверами (в том случае, когда КД выполняет еще и другую задачу) или же снизить
нагрузку на основной КД за счет установки еще одного КД в отдельном
подразделении компании. При использовании Win2k8 в удаленном офисе есть вариант
установить контроллер домена только для чтения (RODC). Тогда в случае
компрометации сервера или банальной кражи оборудования можно не бояться за
нарушение функционирования всего леса (подробности смотри в статье «В лабиринте
AD»). Так мы разгрузим основной КД и снизим нагрузку на Сеть (в том числе и на
внешний канал, если для соединения между офисами используется интернет).

Узкие места могут возникать по нескольким причинам:

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

Теперь разберем некоторые моменты подробнее.

Ищем бутылочное горлышко

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

В новой Win2k8 и Win2k3, которая еще долго будет верой и правдой служить на
серверах, системы мониторинга несколько отличаются, но не настолько, чтобы не
разобраться при смене системы. Диспетчер задач, вызываемый по (в
Win2k8 нужно будет выбрать в меню еще и Start Task Manager) или ,
позволяет во вкладке Performance увидеть состояние основных системных ресурсов (CPU,
ОЗУ) и Сети (во вкладке Networking). В обеих системах можно оценить вклад
отдельного процесса в общую потерю производительности. Если информации
недостаточно, добавляем счетчики производительности. Для этого достаточно
перейти во вкладку «Processes» и выбрать в меню View — Select Columns, после
чего установить флажки напротив нужных пунктов. По умолчанию активировано всего
два счетчика: CPU Usage (загрузка ЦП) и Memory — Private Working Set (Memory
Usage в Win2k3, Использование памяти). Названия некоторых счетчиков в системах
отличаются, но разобраться несложно.

В Win2k3 для наблюдения за производительностью системы в штатную поставку
входит «Монитор Производительности» (вызывается через Старт —
Администрирование — Производительность, perfmon.msc), который выводит показания
активных счетчиков в виде графиков, диаграмм или таблиц. Ведется история
событий, помогающая отследить все изменения. При достижении порогового значения
можно, например, отправить сообщение админу — в общем, выполнить действие.
Подробности о «Мониторе Производительности» и основных счетчиках смотри в статье
«Поставь сервер на
счетчик», опубликованной в X_11_2007.

На сайте Microsoft для Win2k3 доступно еще одно эффективное, хотя и
малоизвестное средство анализа производительности — Server Performance Advisor
V2.0 (SPA). С помощью этой утилиты можно собрать информацию о настройках, данные
со счетчиков с одного или нескольких серверов, отслеживать события (Event
Tracing). По результатам работы получим удобные для чтения и анализа отчеты о
производительности, содержащие предупреждения и рекомендации по устранению
неполадок. В SPA имеется более 90 предварительно настроенных групп коллекторов.
Причем самые востребованные уже настроены! Например, коллектор System Overview
содержит основные системные счетчики: CPU usage, Memory usage, занятые файлы и
TCP-клиенты, top-потребители CPU, а также счетчики для основных серверов —
контроллеров домена, файловых служб AD, IIS, DNS, Terminal Services, SQL и др.

В Win2k8 контроль за основными параметрами системы возложен на Reliability
and Performance Monitor (RPM), который вобрал в себя функции отдельных
приложений, доступных в Win2k3. Запустить его можно несколькими способами: из
меню Administrative Tools, нажатием клавиши Resource Monitor во вкладке
Performance в Task Manager, выбрав пункт в меню Diagnostic в Server Manager или
введя в консоли perfmon.exe. В главном окне RPM увидим четыре графика, выводящие
информацию о загрузке CPU, Disk, Memory и Network в реальном времени. Чуть ниже
расположены таблицы с подробной информацией, разбитой по этим же группам. В
каждой показан процесс и связанные с ним данные (PID, объем ОЗУ, загрузка CPU,
Response Time дисковых операций, количество переданных и принятых сетевых
пакетов и прочее).

Зачастую достаточно одного взгляда на графики и таблицу, чтобы оценить
обстановку и принять решение. Но и это еще не все. «Монитор Производительности»
находится в меню Performance Monitor. По умолчанию активирован только один
счетчик Processor Time, но достаточно выбрать в контекстном меню Add
Counter, как откроется одноименное окно, в котором можно выбрать нужный счетчик.
Полный список охватывает все параметры системы и сервисов. Следующее меню, хотя
и не связано с оценкой производительности, — тем не менее, очень полезно при
поиске неисправностей. Речь идет о Reliability Monitor («Монитор Надежности»).
Справа от графика выводится индекс ожидания появления проблемы System Stability
Index («Системный Индекс Устойчивости»). График Stability Index помогает быстро
найти дату, когда было замечено первое появление проблемы (уменьшился System
Stability Index). В поле System Stability Report показаны детали возникшей
проблемы.

Два меню Data Collector Sets и Reports выступают в роли удобного аналога SPA.
Так, в первом из них содержатся шаблоны коллекторов, которые могут быть
использованы с любой программой, предназначенной для сбора данных. Выполнив,
например, LAN Diagnostics или System Performance (то есть любой коллектор или
группу), в соответствующем подменю в Reports получим полный отчет.

Тюнинг системы

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

Перед внесением изменений сформулируем для себя несколько правил:

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

Среди советов встречаются такие, как отключение «лишних» сервисов и проверка
запланированных заданий, но в Win2k8 изначально запущено только то, что
действительно нужно. Поэтому эти советы больше актуальны для ранних версий
Windows.

Оптимизация сети

Сетевая подсистема в Win2k3/Win2k8 (как, впрочем, и в любой другой ОС)
является многоуровневой. Глубокий тюнинг следует производить на каждом уровне,
начиная от драйвера и NDIS (спецификация интерфейса сетевых драйверов) и
заканчивая уровнем приложений. Начнем «снизу».

Вызываем свойства адаптера и изучаем активные протоколы. Любой протокол
генерирует некоторый трафик, поэтому даже в небольшой сети путешествует гораздо
больше пакетов, чем нужно для ее нормального функционирования. Например,
адаптеру, который смотрит в интернет, часто ни к чему NetBEUI (да и с точки
зрения безопасности, это минус). Поэтому отключаем все лишнее, в том числе и
IPv6 (в нашей стране пока необходимости в нем нет). Параллельно включаем снифер
и отлавливаем «лишние» пакеты, определяя их источник. Если расположить более
быстрый или часто используемый протокол в начале списка, то это позволит
увеличить производительность.

Локальные файлы HOSTS (для TCP/IP) и LMHOSTS (NetBEUI), хранящие адреса и
имена систем, помогают уменьшить количество запросов на разрешение имен. Эти
настройки можно произвести как вручную, так и зайдя в свойства TCP/IP в
настройках сетевой карты, и затем выбрав Advanced. Распространять изменения в
этих файлах можно в небольших сетях вручную, а в AD — при помощи политик.
Присутствие DNS- и WINS-серверов также способно уменьшить количество лишних
задержек.

Кстати, новая концепция ролей в Win2k8 приносит свои плоды: в настройках Сети
после установки системы ничего лишнего не включено, а новые алгоритмы настройки
и оптимизации требуют меньше телодвижений со стороны администратора. Например,
автоматическая настройка TCP Receive Window Auto-Tuning динамически изменяет
размер принимающего буфера TCP, используемого для хранения входящих данных, тем
самым повышая пропускную способность, скажем, при передаче больших файлов на
высокоскоростных каналах (поэтому ключ реестра TcpWindowSize в Win2k8
игнорируется). Средство Compound TCP (CTCP) увеличивает количество одновременно
отправляемых данных — ну, и так далее. Впрочем, кое-что нам оставили и для
ручной настройки.

Нажав кнопку Configure в свойствах адаптера, получаем во вкладке Advanced
доступ к ряду настроек (их количество зависит от конкретного адаптера).
Например, для файлового и FTP сервера рекомендуется задействовать следующие
опции: IPv4, TCP и UDP Checksum offload, Segmentation offload и TCP offload
engine (TOE). Поддержка последнего включается следующим образом:

> netsh int tcp set global chimney = enabled

Для веб-сервера и сервера базы данных желательно активировать еще и
Receive-side scaling (RSS). Но если сетевой адаптер не справляется с нагрузкой,
— наоборот, пробуем по одному отключать все offload настройки. В Link Speed &
Duplex указывается режим работы адаптера (по умолчанию он выбирается
автоматически), а в Transmit/Receive Buffers — буфер приема и передачи. В целях
экономии ресурсов размер буфера по дефолту установлен в минимальное или среднее
значение. При больших нагрузках это чревато потерями пакетов. Если адаптер
позволяет вручную изменить размер буфера, то увеличиваем, не задумываясь.

Параметр Interrupt Moderation по умолчанию установлен в Adaptive.
Проигравшись с настройками, можно попробовать выбрать приемлемый результат между
производительностью Сети и нагрузкой на CPU. Если на сервере несколько CPU и
сетевых карт, то возможна привязка CPU к сетевому адаптеру. Это положительно
скажется на производительности Сети и системы за счет уменьшения количества
«лишних» прерываний. Конечно, это не все, что может сделать админ для разгрузки
Сети. Например, для настройки драйвера http.sys, который используется IIS, есть
целая ветка реестра:

Что-то можно сделать и на прикладном уровне. Например, в ISA Server
реализована функция сжатия данных, передаваемых по протоколу HTTP. Правда, за
меньший трафик придется платить большей нагрузкой на CPU. В медленных сетях
пропускная способность повышается на 30%. Также уменьшается задержка при
передаче информации, хотя нагрузка на процессор не увеличивается более чем на
20%. Для разгрузки сервера терминалов в Computer Configuration — Administrative
Templates — Windows Components — Terminal Services — Terminal Server можно
уменьшить глубину цвета и размер рабочего стола, установить сжатие RDP,
отключить обои и т.д.

Дисковая подсистема

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

Кое-что можно сделать и самому. По умолчанию файл подкачки равен 1.5 объема
ОЗУ и расположен на системном диске. Последний обычно сильно загружен, к тому же
подвержен фрагментации. Поэтому, если имеется несколько дисков, создаем файл
подкачки на каждом. Для этого в Control Panel System выбираем Advanced System
Setting и получаем знакомое окно System Properties («Свойства системы»).
Нажимаем во вкладке Advanced в поле Performance кнопку Setting, снова щелкаем
Advanced, а затем кнопку Change. В появившемся окне снимаем флажок «Automatically
manage paging file for all driver» и указываем, на каких дисках и разделах
следует создать файл подкачки. При этом следует помнить, что использование
нескольких разделов одного диска для файла подкачки, мягко говоря,
нецелесообразно. Своп лучше размещать на разделах с меньшей буквой, на которых,
как правило, скорость повыше.

По умолчанию Windows записывает данные блоками по 64 Кб, но жесткие диски и
приложения могут использовать блоки других размеров. Данные в этом случае
придется записывать на несколько секторов, что снижает производительность. В
состав Win2k8 и Win2k3 SP1 входит программа Diskpart, предназначенная для
создания разделов диска. С ее помощью можно задать другое смещение. Пользоваться
программой просто. Для запуска в командной строке набираем diskpart.exe. Далее
командой «List Disk» выводим список дисков, выбираем нужный диск — «Select Disk
1», создаем раздел «Create Partition Primary Align=64» и присваиваем ему букву
(«Assign Letter=D»). Помни, что Diskpart уничтожает данные, поэтому
предварительно создай резервную копию!

Также стоит отключить индексацию файлов для (якобы) быстрого поиска и
компрессию диска (если взведен флажок «Compress this drive to save disk space»).
И, конечно же, не забываем о периодической дефрагментации (Свойства диска —
Tools — Defragment Now). В подменю Shadow Copies находятся настройки теневых
копий. Если резервирование производится другими средствами, то для повышения
производительности их можно отключить или изменить алгоритм работы.

Не помешает знать и о некоторых параметрах реестра (они подходят и для
Win2k3). Так, параметр NumberOfRequests, зависимый от драйвера сетевой карты,
позволяет задать количество запросов, ускоряя работу за счет распараллеливания.
Драйвер сам устанавливает оптимальное значение, но рекомендуется установить его
в диапазоне от 32 до 96.

Установка в 0 ключа CountOperations позволит отключить некоторые счетчики,
что также повлияет на производительность в лучшую сторону:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\I/O System\CountOperations

Установка в 1 (REG_DWORD) ключа DontVerifyRandomDrivers запрещает
тестирование и проверку некорректно работающих драйверов:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\Memory
Management\DontVerifyRandomDrivers

В Win2k8 используется сложный алгоритм, индивидуально управляющий приоритетом
I/O. Если для экспериментов ты захочешь его отключить, установи в 0:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\ GUID>\DeviceParameters\Classpnp\IdlePrioritySupported\I/O Priorities

Чтобы запретить обновление даты последнего обращения к файлу, устанавливаем в
1 (REG_DWORD) ключ:


Это только основные параметры. А подробную информацию по настройке дисковой
подсистемы можно найти в документе «Disk Subsystem Performance Analysis for
Windows» на сайте Microsoft.

Точность хирурга

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

Iis о настройке быстродействия

Ключевое свойство Microsoft IIS 5.0 — высокая производительность. Для повышения уровня производительности IIS разработчики Microsoft усовершенствовали многие компоненты IIS, например Active Server Pages (ASP). Для максимально быстрого подключения IIS необходимо внести некоторые изменения в конфигурацию IIS и настройки системы Windows 2000.

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

Значительное повышение производительности IIS 5.0 обусловлено свойствами системы Windows 2000, использующей многопроцессорную конфигурацию. Приложения, работающие на многопроцессорных системах Windows 2000, функционируют намного быстрее, чем приложения, запущенные на многопроцессорных системах Windows NT. Эффективная работа нескольких процессоров повышает производительность ASP. Тестирование производительности приложений (с помощью таких программ, как Vertigo Software`s Fitch & Mather Stocks 2000 – FMStocks 2000) показывает, что по производительности система Windows 2000 превосходит Windows NT 4.0. Так как IIS 5.0 запускается поверх Windows 2000, повышение эффективности работы системы Windows 2000 как сервера приложений оказывает влияние на быстродействие IIS 5.0.

Дополнительные характеристики, такие как Application Protection в IIS 5.0, управление компонентами и работа с общими файлами в Windows 2000, также влияют на производительность IIS 5.0. Давайте рассмотрим эти возможности и некоторые специальные настройки IIS 5.0 с точки зрения предстоящего увеличения производительности.

Application Protection

Функция Application Protection в IIS 5.0 дает возможность запускать приложения в изолированных областях памяти. Это позволяет увеличить стабильность системы, при выполнении обработки приложений вне IIS.

Существует три режима защиты приложений Application Protection в IIS 5.0 — Low (IIS Process), Medium (Pooled) и High (Isolated). Можно изменить настройку Application Protection на закладке Home Directory страницы Properties для сайта, как показано на Рис.1, или на странице Virtual Directory Properties (чтобы добраться до обеих страниц Properties, откройте Internet Services Manager (ISM), нажмите правую кнопку мыши на Web-сайте или Virtual Directory, который хотите изменить, а затем выберите Properties). Приложение ASP в режме защиты Low (IIS Process) работает в том же пространстве процесса (т.е. inetinfo.exe), что и сам IIS. Если происходит отказ приложения и нарушение доступа к памяти у IIS или серьезный сбой другого важного серверного процесса, то IIS и все другие Web-приложения тоже могут завершиться аварийно.

Рис.1. Выбор Application Protection в IIS 5.0

При использовании режима Medium (Pooled) Application Protection приложение запускается со всеми другими связанными с ним приложениями в процессе dllhost.exe. Как и при режиме защиты Low (IIS Process), если одно из приложений, использующее способ защиты Medium (Pooled) выходит из строя, это может послужить причиной сбоя всех приложений, запущенных в той же рабочей области.

Настройка защиты High (Isolated) в IIS 5.0 подобна настройке Run in separate memory space в IIS 4.0. При использовании этой настройки для ASP-приложения в IIS 4.0 оно помещается в отдельный пакет Microsoft Transaction Server (MTS). Передача приложения к MTS увеличивает стабильность, отделяя работу приложения от IIS, но в то же время значительно снижая производительность приложения. Это связано с тем, что внепроцессное исполнение пакета MTS приводит к непроизводительным издержкам.

Настройка Application Protection в IIS 5.0 выполняется не так, как настройка защиты в IIS 4.0. При выборе ASP-приложения для работы в режиме High (Isolated) в IIS 5.0 ISM создает новое COM+ приложение и помещает в него ASP (в Component Services Explorer название нового приложения будет выглядеть как IIS–, заключительная часть имени – DNATestProject1KLS является именем приложения). Каждое высокозащищенное приложение запускается в отдельной копии dllhost.exe, и если происходит сбой приложения, это не станет причиной остановки для других приложений.

Приложения, запускаемые в Medium (Pooled) или High (Isolated) режимах защиты в IIS 5.0, показывают значительное повышение производительности по сравнению с идентичным приложением, выполняемым в IIS 4.0, согласно статье «Leveraging ASP in IIS 5.0» в Microsoft Developer Network (MSDN). Автор статьи обращает внимание на то, что использование установки защиты Medium (Pooled) в IIS 5.0 обычно дает более высокую производительность, чем внутрипроцессные приложения в IIS 4.0. Этот способ, связанный с установкой защиты Medium (Pooled) в IIS 5.0, перемещает приложение в более изолированную среду и, кроме того, увеличивает производительность. Даже при установке защиты High (Isolated) приложение будет выполняться быстрее, чем если бы оно было запущено в IIS 4.0.

Компоненты

Управление компонентами в IIS 5.0 также повышает производительность по сравнению с IIS 4.0. Всем разработчикам для IIS 5.0 при работе с компонентами необходимо помнить о предоставлении механизму ASP права отпускать объект в тот момент, когда приложение в нем больше не нуждается. Освобождение ненужных объектов освобождает ценные ресурсы.

IIS 4.0 не освобождает объекты до тех пор, пока страницу со ссылкой на объект не перестанут использовать. Для страниц, обрабатываемых длительное время, задержка освобождения объекта может добавить значительные непроизводительные издержки в работе приложения. Низкая производительность является результатом того, что выполнение страницы не завершается до тех пор, пока все объекты не обработаны, а код ASP не выполнен до конца.

Выигрыш в производительности обеспечивается за счет быстрого освобождения ненужных объектов, и это особенно заметно, когда многие пользователи обращаются к приложению одновременно. Когда это происходит в IIS 4.0, каждая страница привязывает объект и держит его в памяти до тех пор, пока страница заполняется, используя в это время дополнительные ресурсы и таким образом снижая производительность.

Для освобождения объекта можно использовать код VBScript. Например,

присвоит переменной oCust, которая содержит ссылку на объект, ключевое слово Nothing, удаляющее ссылку. Этот код заставляет механизм ASP немедленно освободить объект, на который указывает oCust.

Дополнительные настройки

Метабаза IIS 5.0 содержит параметр ASPProcessorThreadMax, который в IIS 4.0 назывался ProcessorThreadMax и находился в реестре. Разработчики Microsoft изменили значение по умолчанию для этого параметра с 10 в IIS 4.0 на 25 в IIS 5.0. Это изменение может повысить производительность, поскольку процесс ASP будет обрабатываться большим количеством потоков. Если система имеет достаточно процессоров и скорости их работы хватает для использования большего числа потоков, новая настройка позволит сделать процесс ASP более эффективным. При использовании IIS 5.0 эту настройку указывать не нужно, пока тестирование системы не покажет, что настройка по умолчанию является узким местом.

Если на сервере установлена служба Indexing Service, то можно повысить производительность, используя ISM для отключения параметра Index this resource . Если приложение создает HTML-файл из базы данных или другого источника, и не используются статические HTML-файлы, которые пользователям необходимо будет найти, то в этом случае параметр Index this resource можно отключить, так как службе Indexing Service индексирование таких файлов, скорее всего, не потребуется. Отключение этого параметра сокращает непроизводительные издержки сервера при выполнении ASP-приложения, что может несколько повысить производительность.

Можно использовать закладку Performance страницы Properties для настройки памяти, которая применяется в IIS 5.0 для обработки подключений и ресурсов Web-сайта. В документации по IIS говорится о необходимости установки ползунка Performance Tuning немного выше того количества ответов в день, которые ожидается получать на сайте. Можно изменить настройку «ответов в день», перемещая ползунок в соответствии с количеством ответов (т.е. менее чем 10 000, менее чем 100 000, более чем 100 000). При перемещении ползунка к большему числу задействуется больший объем доступной памяти для обработки ресурсов Web-сайта.

Параметр Enable process throttling – новый на закладке Performance в IIS 5.0, позволяет IIS ограничивать время процессора, которое механизм ASP расходует на выполнение приложений с установленным режимом защиты High (Isolated). Когда включается этот параметр, приложения с высоким уровнем защиты по умолчанию могут использовать не более 10 % времени работы процессора в течение 24 часов. Если приложение превышает этот предел, IIS записывает сообщение в журнал регистрации событий. Можно активизировать Enforce limits, чтобы заставить IIS выбрать более решительное действие, например, остановку всех внепроцессных приложений, если приложение превысит предел. Если планируется ускорить выполнение процесса, следует предварительно почитать документацию по IIS.

Защитные функции вступают в компромисс с производительностью IIS 5.0. Активизация настроек защиты в IIS или Windows 2000 включает функции, которые, должны контролировать или выполнять какие-либо процессы. Защита добавляет уровень непроизводительных издержек в каждую задачу, оказывая на нее воздействие. Если другой защиты доступа, кроме анонимного, не нужно, то другие типы защиты (например, Secure Sockets Layer (SSL)) включать не требуется.

Защита существует во многих местах. Windows 2000, IIS, COM+ и SSL имеют настройки, которые могут воздействовать на систему, делая ее более или менее защищенной. Необходимо понять, насколько мощная защита требуется системе, и как уровень защиты будет влиять на ее производительность. Например, совместное тестирование в лаборатории, где я работал, показало, что отдельное приложение, использующее Visual Basic (VB) и ASP, могло обслуживать 250 страниц в секунду. Изменение только одной настройки защиты в COM+ увеличивало производительность на 950-1000 страниц в секунду.

Доступ к общим файлам

Можно использовать режим File Sharing системы Windows 2000 для повышения производительности IIS 5.0, изменяя настройку File Sharing для сетевого адаптера, который обрабатывает входящие HTTP-запросы. Для этого нужно нажать Start, Settings, Network и Dialup Connections и перейти к окну, которое показано на Рис.2. Затем нажмите правую кнопку мыши на том подключении, которое хотите изменить, и выберите Properties. На закладке Server Optimization следует выбрать Maximize data throughput for network applications и нажать OK. Эта настройка оптимизирует использование памяти системой Windows 2000 применительно к сетевым приложениям, которые выполняют кэширование, таким как Microsoft SQL Server и IIS. Эта настройка также предохраняет Windows 2000 от выгрузки рабочих данных IIS, перенося их из памяти на диск при снижении объема доступной памяти системы. Предотвращение такой выгрузки может резко поднять производительность. На сервере, который имеет несколько адаптеров (т.е. многодомном сервере), можно установить настройки File Sharing для каждого используемого подключения.

Рис.2. Окно диалога File Sharing

Аппаратный фактор

Аппаратное обеспечение сильно влияет на производительность IIS 5.0. Группа разработчиков лаборатории компании Microsoft тестировала различные аппаратные платформы для Web-серверов IIS. Разработчики сравнили производительность IIS на мощных серверах с оперативной памятью 512 Мбайт, быстродействующими дисками и несколькими процессорами с производительностью IIS на серверах с меньшим объемом оперативной памяти (128 Мбайт), стандартными IDE-дисками и несколькими процессорами. Лучшими Web-серверами были признаны те, которые имели несколько быстрых CPU. Ни размер памяти, ни тип интерфейса диска (например, SCSI, IDE), ни скорость процессора не оказывала значительного влияния на производительность IIS. Результаты тестирования показали, что можно добиться заметного роста производительности, увеличивая количество процессоров. Если использовать Network Load Balancing (NLB) или аппаратное решение (например, маршрутизатор, который обеспечивает циклическое переключение к DNS), можно повысить производительность, добавляя большее количество компьютеров.

Лабораторные тесты и практический опыт внедрения IIS 5.0 на системе Windows 2000 показывает, что использование настроек по умолчанию и внесение выборочных изменений только в определенные параметры будет способствовать повышению производительности. Не изменяйте настройки по умолчанию для сетевого интерфейса системы до тех пор, пока не протестируете производительность системы и не сможете точно оценить, как отразится на ней каждое изменение.

Ускорьте свой IIS

Есть ли способ повысить производительность вашего IIS, изменив некоторые параметры конфигурации?

Или у вас есть какие-либо советы в целом о том, как повысить производительность приложения ASP.NET?

  • Не забудьте отключить ‘debug’ в web.config
  • не использовать сопоставление файлов подстановок.
  • Используйте httpCompression для улучшения воспринимаемой производительности.
  • Полоса пропускания дроссельной заслонки для улучшения общей воспринимаемой производительности.
  • Попробуйте использовать IIS7 для приложений .net

Ваш первый порт вызова должен быть здесь: —

Вы заглянули в Кэширование? или микро-кэширование Посмотрите http://www.dnrtv.com/default.aspx?showNum=85.

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

Если у вас есть доступ к серверу IIS, вы можете изменить его, включая:

Сжатие HTTP — отлично подходит для статического контента, такого как файлы JS и CSS.

Предварительная компиляция приложения ASP.NET делает его быстрее. Сборка релиза — плюс.

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

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

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

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

Настройки производительности и оптимизации для веб-службы ASMX на IIS7

Моя среда: Windows Server 2008, SQL Server 2008, IIS 7, .NET 4.0 и веб-служба .ASMX.

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

Я нашел эту статью на MSDN, хотя. Просто не уверен, применимо ли это к IIS 7. Итак, что мне нужно сделать здесь в отношении настроек и конфигураций IIS 7?

1 ответ

Две основные функции производительности IIS 7:

«IIS 7 предоставляет мощное унифицированное средство для кэширования вывода, интегрируя возможности ASP.NET для динамического кэширования вывода с возможностями статического кэширования вывода, которые присутствовали в IIS 6.0. IIS также позволяет более эффективно и рационально использовать пропускную способность, используя общие механизмы сжатия, такие как Gzip и Deflate «

IIS предоставляет следующие параметры сжатия: — только статические файлы — только динамические ответы приложений — как статические файлы, так и динамические ответы приложений

В IIS 7 вы можете настроить кэширование вывода для повышения производительности вашего веб-сервера, сайта или приложения. Когда пользователь запрашивает веб-страницу, IIS обрабатывает запрос и возвращает страницу в браузер клиента. Если вы включите кэширование вывода, копия этой обработанной веб-страницы будет храниться в памяти на веб-сервере и возвращаться в браузеры клиентов при последующих запросах к тому же ресурсу. Это устраняет необходимость повторной обработки страницы каждый раз, когда она запрашивается. Это полезно, когда ваш контент зависит от внешней программы для обработки, например, с программой Common Gateway Interface (CGI), или содержит данные из внешнего источника, например из удаленного общего ресурса или базы данных.

Как оценить посещаемость (количество пользователей) на сайте IIS

Как быстро оценить текущее количество подключений пользователей к сайтам на веб сервере IIS, работающем на Windows Server? Подобная информация позволит точнее оценить и спрогнозировать нагрузку на сервер, выбрать оптимальное время для проведения обслуживания и обновления сайта, спрогнозировать нагрузку на сервер при увеличении количества пользователей.

Проще всего определить количество активных сессией пользователей на веб сайте IIS при помощи счетчиков производительности в мониторе производительности Windows (Performance Monitor).

Откройте консоль Performance Monitor, выполнив команду perfmon и перейдите в консоль монитора производительности (Monitoring Tools —> Performance Monitor).

Далее нужно добавить в окно монитора необходимые нам счетчики (по умолчанию в окне отображается счетчик общей загрузки CPU — его можно удалить). Чтобы добавить новый счетчик, нажмите зеленую кнопку в панели инструментов (на скриншоте она выделена) или нажмите комбинацию клавиш Ctrl+N.

В списке доступных категорий счетчиков найдем и развернем группу Web Service. В этой категории нас интересуют три счетчика:

  • CurrentAnonymousUsers – количество анонимных пользователей IIS;
  • CurrentNon-AnonymousUsers – количество авторизованных (неанонимных) пользователей IIS;
  • CurrentConnections – общее число активных подключений на сервере IIS.

Выберем нужный счетчик и в поле экземпляров счетчика (Instances of selected objects) выберем один или несколько сайтов IIS, для которых нужно отобразить информацию о подключениях. Информация по пользователям всех сайтов на сервере содержится в экземпляре _Total. Осталось нажать кнопку Add >>, чтобы нужный счетчик переместился в список добавляемых счетчиков в правом окне.

Точно так же добавим все необходимые счетчики и нажмем ОК.

Теперь в консоли Performance Monitor в режиме реального времени будет отображаться информация о количестве активных подключений (сессий) пользователей на веб сервере/сайте IIS (по умолчанию значения счетчиков выводятся в виде линейных графиков). Выбрав в нижней панели любой из счетчиков можно посмотреть его текущее (last), среднее (average), минимальное (minimum) и максимальное (maximum) значение за данный период времени.

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

Доступ к данным счетчиков производительности для сайтов IIS можно получить и из PowerShell. Для этого достаточно использовать командлет получения данных из счетчика производительности Get-Counter.

Список всех доступных счетчиков производительности для службы Web Service можно вывести так:

Чтобы получить информацию о текущем количестве активных подключений на сервере IIS (счетчик \Web Service(*)\Current Connections) воспользуйтесь такой командой:

Get-Counter -Counter “\Web Service(*)\Current Connections”

Как вы видите, данная команда вернула как суммарное количество подключений к серверу IIS, так и статистику для каждого из сайтов.

  • Значения нескольких счетчиков можно вывести, указав их через запятую;
  • С ключем Continuous информация о значении счетчика будет выводится в консоль постоянно, пока не будет выполнено прерывание командой CTRL+C.

Как мы уже говорили, можно получить количество активных сессии для конкретного сайта IIS. Например, чтобы получить текущее количество соединений на сайте с именем Site1, выполните команду (вы можете указать имя сервера, на котором проверяется значение счетчика, при проверке количества подключений на сайте локально, указывать localhost недопустимо):

Get-Counter «web service(Site1)\current connections» -ComputerName web-app01

Чтобы не указывать каждый раз имя сервера, можно использовать переменную окружения COMPUTERNAME

Get-Counter «web service(Site1)\current connections» -ComputerName $env:COMPUTERNAME

Для получения числового значения счетчика «current connections» всего веб-сервера IIS (суммарная нагрузка на IIS) можно использовать такой код:

((Get-Counter -Counter ‘web service(_total)\current connections’ -computer $env:COMPUTERNAME) | Select-Object -Expand countersamples).Cookedvalue

Попробуем с помощью простого скрипта создать несколько дополнительных сессии с нашим сайтом и проверить значение счетчика. Можно накрутить количество обращений к IIS с помощью с помощью командлета Invoke-WebRequest, а можно просто открыть несколько окон в браузере:

$counter = 20
for($i=1;$i -le $counter;$i++)<
$SiteAdress = «http://localhost:9666/»
Start-Process $SiteAdress
>

После этого проверьте значение счетчика current connections и убедитесь, что он увеличиться.

Если на сервере запушено несколько сайтов IIS, и нужно получить количество подключений к каждому из них в табличном виде, можно воспользоваться таким скриптом (для получения данных из IIS в PowerShell нужно загрузить модуль WebAdministration):

import-module webadministration
function get-CurrentConnection($Site) <
Get-Counter «web service($Site)\current connections,web service($Site)\ Bytes Received/sec,web service($Site)\Bytes Sent/sec» -ComputerName $env:COMPUTERNAME
>
$IISsites = dir IIS:\Sites | Select Name
$CurrentConnection = @()
foreach ($site in $IISsites)
<
Write-Host $site
$ConnCount = New-Object psobject | get-CurrentConnection -Site $site.name
$CurrentConnection += $ConnCount
>
$CurrentConnection|out-gridview

Также вы можете вывести числовые значения счетчиков подключений по всем сайтам так (первое значение – суммарное количество подключений к IIS):

Get-wmiObject -class Win32_PerfRawData_W3SVC_WebService | select-object -expand currentconnections

Также вы можете отобразить информацию о количество полученных/переданных данных для каждого сайта или всего веб сервера с помощь счетчиков web service(sitename)\ Bytes Received/sec и web service(sitename)\Bytes Sent/sec».

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

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – установка.

Как я и обещал в посте несколько дней назад, начинаю писать серию постов типа инструкций шаг за шагом «как это установить и настроить» для тех админов, у которых действительно мало времени «на найти и разобраться», да еще если все это на английском языке. Кстати, кому таки не лениво – вот здесь очень хорошая подборка англоязычных документов под общим названием «Windows Server 2008 Step-by-Step Guides» — очень полезно в работе. Надеюсь, найдутся время и ресурсы, чтобы их тоже «отфильтровать» и сделать на их базе русские версии.

Если вам не интересны мои мысли «почему я пишу про IIS 7.0», можете смело пропустить пару абзацев.

В ближайший месяц я буду писать о веб-платформе от Microsoft, и в основном это будет касаться администрирования Internet Information Services 7.0 (IIS 7.0), входящего в состав Windows Server 2008. Это не значит, что я не буду писать ни о чем другом – конечно буду, у меня масса планов и тем с барселонского TechEd IT Forum 2008, в основном по направлению Windows Server 2008 R2, просто про администрирование IIS7 буду писать в этот месяц намного чаще и более последовательно, чем я это делал ранее. Поэтому даже те, для кого тема IIS7 не интересна, смогут как минимум раз в неделю находить у меня на блоге что-то интересное по другим тематикам.

Почему именно IIS 7.0? Здесь несколько причин. Во-первых, в уже упомянутом сборнике документов «шаг за шагом» «Windows Server 2008 Step-by-Step Guides» по странному стечению обстоятельств документа по IIS 7.0 почему-то нет. Во-вторых, как показывает опыт семинаров TechNet в Украине – знания, и даже можно сказать – представления многих админов о технологиях Microsoft для веб базируются на «сказках-страшилках» конца прошлого века, и хотелось бы показать всем желающим простой путь попробовать все технологии самостоятельно, без каких-то предрассудков и прочих ОБС. В-третьих – мне самому, человеку, который достаточно долгий период своей жизни занимался вебом вообще и IIS в частности – а я помню и IIS 2.0, и 3.0, и 4.0 и, конечно же, 5.0 – эта тема близка и интересна, и могу сказать, что за 10 лет в этом направлении Microsoft сделал существенные, даже можно сказать – эпохальные шаги вперед. Потому хотелось бы поделиться и опытом, и знаниями в этой прогрессирующей области с коллегами. В-четвертых – небольшой сюрприз в рамках проводимой в Украине акции для тех, кто разворачивает и управляет веб-серверами под управлением продуктов Microsoft – украинский офис Microsoft проводит акцию, по которой вы можете получить лицензионный Windows Server 2008 Web Edition (коробочная версия) бесплатно для хостинга ваших проектов и сайтов в Интернете. Так что торопитесь получить такой легальный продукт – пишите через блог на почту. И, наконец, в-пятых – в Киеве проводится полигон по веб-технологиям Microsoft, в том числе и IIS 7.0, так что мои статьи послужат хорошим фоном для такого мероприятия.

Ну, вроде это вcе наиболее веские причины писать в ближайший месяц о IIS 7.0. Кроме одной – зачем вообще админу знание IIS 7.0, который, в принципе, больше является платформой для разработчиков, на которой они делают свои веб-проекты? Проблема в том, что, как показывает опыт, разработчики не очень «напрягаются» созданием архитектуры и проработкой деталей веб-проекта, таких, как безопасность, администрирование, масштабирование и т.п. будущего работаеющего решения. И все это становится головной болью админа. Другая головная боль – это работодатели, которые часто под словом «компьютерщик» понимают, что человек может и спаять сгоревшую плату, и сетку настроить, и программку бухгалтерскую написать. И конечно же – веб сайт родной фирмы «Рога и Ко» сделать – как же без него. А то, что в ИТ отрасли есть глубокая специализация – никого не волнует. И вот потом и пишет мне в Live Messenger такой админ – «Игорь, а что делать?! За что хвататься?!», или если такого «Игоря», который бы подсказал, нет рядом – начинается такое.

Вроде, мотивы мои всем понятны. получилось довольно длинно, обещаю, сами технические части будут куда короче. Итак.

Часть 1. Установка IIS 7.0

Первый вопрос, который мне задают – что такое веб сервер под Windows, что нужно установить? Ответ – вебсервер под Windows – это служба IIS 7.0. Следующий вопрос – где взять IIS 7.0, откуда скачать? Ответ очень простой – IIS 7.0 (как и предыдущие версии, начиная с IIS 5.0) интегрирован в саму серверную ОС Microsoft Windows Server 2008 (а предыдущие версии IIS – соответственно в Windows Server 2003 и Windows 2000) и устанавливается как роль Windows Server. Тогда более тривиальный вопрос – где взять «настоящий» Windows Server 2008? Пробную версию Windows Server 2008 для всех экспериментов и тестирования рекомендую брать только с сайта Microsoft http://www.microsoft.com/windowsserver2008 — проверенная и гарантированно правильная версия (только не забудьте установить все обновления). Серийный номер для Windows Server 2008 не требуется – вы просто при установке в мастере установки оставляете его пустым и на вопрос, хотите ли вы все же его заполнить – гордо отвечаете НЕТ. Фактически, если вы при установке или в ходе эксплуатации таки введете настоящий продуктовый номер – вы получите «настоящую» версию. Версия без введенного серийного номера работает 60 дней, после чего требует активации. Мало кто любит читать иструкции при загрузке файлов, особенно те, которые написаны мелким шрифтом – на самом деле, на странице загрузке есть ссылка на инструкцию, какой скрипт надо запустить, чтобы сбросить счетчик активации Windows снова на 60 дней. Такую операцию надо не забыть сделать до истечения 60дневного срока (например, на 59й день эксплуатации). Всего вы можете посторить операцию сброса счетчика 3 раза – т.е. пробную версию можно эксплуатировать 240 дней, что вполне достаточно с тем, чтобы распробовать плюсы и минусы системы. Ну а для желающих уже сейчас эксплуатировать лицензионный Windows Server 2008 для своих веб-проектов – напоминаю про акцию, пишите.

Теперь о выборе редакции, которых доступно аж 4 – Datacenter, Enterprise, Standard, Web Edition. Пожалуйста, подходите более ответственно к их выбору. Зачем, ну зачем использовать Enterprise для запуска веб-сайтов – «шоб було?». Для таких задач есть оптимизированная редакция Web Edition. Сравнение возможностей разных редакций можно найти там же, на официальном сайте http://www.microsoft.com/windowsserver2008. Кроме того, некоторые соображения по использованию лицензионных соглашений и виртуализации в разных редакциях я написал на этом блоге ранее.

После установки экземпляра Windows Server 2008 и его конфигурации (если это также вызывает затруднения – смотрим видео с семинара по Windows Server 2008) переходим непосредственно к установке IIS 7.0. Что нового в IIS 7.0, какие модули включены в него и т.д. – я рассматривать не буду, все теоретические выкладки можно найти в электронной версии журнала TechNet Magazine, которая выходит в том числе и на русском. IIS 7.0 были посвящены 2 статьи в мартовском и июльском номерах журнала. Рекомендую ознакомиться с ними перед практическим применение – знание теории, пусть даже в сжатой форме весьма полезно.

Основным нововведением в направлении установки различных компонент и служб в Windows Server 2008 является понятие «роли». Роль представляет из себя набор всех необходимых компонент, настроек системы, безопасности и т.п., которые необходимы для выполнения определенной задачи. Кроме того, имеется также информация о взаимодействии ролей между собой – одна роль может работать как подмножество другой и, наоборот – роли могут конфликтовать между собой – об этом администратор будет уведомлен при установке такой роли поверх уже существующих. Установку и конфигурацию всего необходимого система выполняет автоматически при выборе конкретной роли. Такой подход гарантирует, что даже в случае ошибки администратора, связанной с установкой той или иной роли, не требуемой в текущий момент – система будет функционировать нормально и это не затронет работоспособность других ролей. Как впрочем, это также существенно упрощает и сам подход к управлению системой Windows Server 2008 в целом.

Управление ролями осуществляется через стандартную оснастку управления Windows Server 2008 – Server Manager или в процессе начальной конфигурации сервера через Initial Configuration Tasks.

IIS 7.0 устанавливается как роль Windows Server 2008. Для этого требуется:

1. Запустить оснастку Server Manager из меню Start или из панели Quick Launch. Server Manager по умолчанию стартует автоматически при входе администратора в систему. Server Manager является основным инструментом управления сервером Windows Server 2008.

2. В оснастке на стартовой странице убедиться, что сервер сконфигурирован правильно. Желательно проверить наличие статического IP адреса. Если он не установлен, его можно поменять тут же, из консоли Server Manager, открыв в правой панели по линку «View Network Connections» сетевые интерфейсы.

3. Выбираем в левой панели Server Manager пункт Roles, в правой панели видим список текущих ролей. В зависимости от редакции ОС и установленных ролей список может варьироваться. В данном примере ни одна роль не установлена.

4. Для установки новой роли используем в правой панели в разделе «Roles Summary» линк «Add Roles».

5. Запускается мастер установки ролей «Add Roles Wizard», пропускаем первую страницу «Before You Begin» мастера, нажав кнопку «Next >»

6. На странице «Select Server Roles» в списке ролей выбираем роль «Web Server (IIS)». Список ролей может отличаться в зависимости от редакции. Данный список соответствует редакции Windows Server 2008 Enterprise Edition x64.

7. При выборе роли «Web Server (IIS)» мастер автоматически предлагает установить сервисы, которые требуются для функционирования веб сервера. Это службы активации процессов, фактически, они обеспечивают среду исполнения процессов, обслуживающих вебсайты. Соглашаемся с установкой данных служб путем нажатия кнопки «Add Required Features» и нажимаем кнопку «Next >» в мастере.

8. На странице «Select Role Services» отображается список всех доступных модулей (сервисов), входящих в состав IIS 7.0, представляющих 3 большие группы – Web, Management и FTP – и внутри сгруппированых по назначению – общие модули для поддержки HTTP Common HTTP Features, модули для исполнения сценариев и приложений Application Development, модули управления журналированием и диагностикой Health and Diagnostics, модули обеспечения безопасности Security, производительности Performance, модули управления и совместимости с предыдущей версией IIS 6.0 Management Tools, и, наконец, модули FTP. По умолчанию роль веб сервера IIS 7.0 устанавливается и конфигурируется в минимальном наборе из 9 модулей:

a. только для работы со статическим HTML контентом (модули из Common HTTP Features),

b. только с подключением анонимных пользователей и с фильтрацией вредоносных запросов (Security),

c. с базовыми модулями для журналирования запросов к вебсайтам на сервере и просмотра очереди запросов (Health and Diagnostics),

d. с модулем сжатия статического контента при передаче страниц клиенту HTTP (Performance),

e. и консоли администрирования в режиме локального подключения к веб серверу IIS Management Console.

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

10. При отметке отдельного модуля для добавления, также, как и при выборе роли, мастер автоматически проводит проверку всех связей и зависимостей и предлагает установить дополнительные модули, без которых функционирование выбраного невозможно. В данном примере для установки выбран модуль ASP.NET и мастер автоматически запрашивает разрешение на установку других модулей и служб, необходимых для его работы. Соглашаемся с установкой данных служб и модулей путем нажатия кнопки «Add Required Role Services». По окончанию выбора всех модулей нажимаем кнопку «Next >» в мастере.

11. На странице «Confirm Installation Selection» отображается для подтверждения информация о всех выбранных модулях, которые будут установлены. Также отображаются служебные и информационные сообщения рекомендательного характера. Например, рекомендация после установки роли IIS 7.0 выполнить обновления ОС или установить Windows System Resource Manager (WSRM), который позволяет обеспечить распределение ресурсов системы при выполнении веб-приложений. Нажатие кнопки «Next >» на этой странице устанавливает весь указанный перечень модулей.

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

13. После закрытия окна мастера установки роли в левой панели консоли Server Manager в разделе «Roles» среди других ролей появляется подраздел «Web Server (IIS)». В правой панели отображается информация о состоянии всех установленных ролей.

14. Выбираем подраздел «Web Server (IIS)» в левой панели Server Manager, в правой панели отображается информация о работе роли веб сервера. Здесь представлены:

a. Events: агрегированный список записей из всех журналов событий ОС за последние 24 часа, имеющих отношение к работе веб служб,

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

c. Role Services: в данном случае – список всех модулей IIS 7.0 с указанием установлен данный модуль или нет и с возможностями старта мастера установки/удаления модулей данной роли (о котором мы говорили выше),

d. Resources and Support: наиболее интересный раздел информации о каждой роли, который содержит в себе базу знаний с рекомендациями по дополнительной более тонкой настройке той или иной роли для отдельных сценариев использования. Рекомендуется к широкому использованию.

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

Илон Маск рекомендует:  Asp семейство session staticobjects
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL