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 более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.

Однако 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.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

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

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

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

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

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

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

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

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

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

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

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Работа конвейера веб-сервера IIS

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

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

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

HTTP.sys

Драйвер уровня ядра HTTP.sys является посредником между приложением и операционной системой. В архитектуре IIS он выполняет две задачи:

HTTP.sys является протокольным слушателем (protocol listeners) по умолчанию в IIS. То есть HTTP.sys прослушивает все запросы, которые, используют протоколы HTTP и HTTPS, и затем передает эти запросы другим компонентам IIS для дальнейшей обработки.

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

Порт завершения ввода-вывода

Для максимизации числа одновременно обрабатываемых запросов IIS использует специальное API, которое называется портом завершения ввода-вывода (Input/Output Completion Port). IIS имеет выделенный пул потоков для обработки операций ввода/вывода и управления очередью запросов. При обработке запросов этот API взаимодействует с драйвером HTTP.sys.

World Wide Web Publishing Service (W3SVC)

World Wide Web Publishing Service или Служба веб-публикации является адаптером над драйвером HTTP.sys и выполняет следующие функции:

Мониторинг показателей производительности

До версии IIS 7.0 служба веб-публикации также управляла рабочими процессами приложений. Но начиная с IIS 7.0 за эту функцию отвечает Windows Process Activation Service.

Windows Process Activation Service (WAS)

Данная служба была выделена начиная с IIS 7.0. Ее предназначение — управление рабочими процессами. WAS состоит из трех основных компонентов:

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

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

интерфейс неуправляемых адаптеров прослушивателей (unmanaged listener adaptor interface): предоставляет интерфейс для прослушивателей запросов, которые не относятся к протоколу HTTP

Обработка запросов в IIS

Теперь рассмотрим поэтапно работу конвейера IIS по обработке входящих запросов.

Пользователь посылает HTTP-запрос, обращаясь через браузер к определенному ресурсу на сервере. Этот запрос перехватывается драйвером HTTP.sys.

Драйвер HTTP.sys обращается к WAS для получения конфигурационных данных для запрошенного адреса URL

Менеджер конфигурации WAS считывает данные из файла applicationhost.config, в частности пул приложения и конфигурационные настройки сайта

Считанные данные WAS передает службе веб-публикации IIS (служба W3SVC)

Служба веб-публикации использует полученные от WAS данные для конфигурации HTTP.sys. Затем драйвер HTTP.sys помещает пришедший запрос в очередь порта завершения ввода-вывода (I/O completion port), которую обрабатывает WAS.

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

В рамках запущенного рабочего процесса ASP.NET проверяет, сколько запросов обрабатывается в текущий момент времени. Если их число превышает лимит по умолчанию в 5000 запросов, то новый запрос помещается в очередь. Однако если очередь достигла своего лимита в 1000 запросов, то данный запрос отвергается, и в ответ клиенту посылается статусный код ошибки 503.

Если запрос направлен к статическому файлу, который не содержит кода .NET-языков, то ASP.NET посылает содержимое этого файла в порт завершения ввода-вывода IIS, а оттуда — пользователю, сделавшему запрос. В остальных случаях ASP.NET отправляет запрос в пул потоков CLR.

CLR обрабатывает запрос. На этой стадии запускается непосредственно код нашего веб-приложения или веб-сайта, размещенного на веб-сервере.

После того, как среда CLR закончит обработку запроса, она посылает результаты драйверу HTTP.sys, а тот — на порт завершения ввода-вывода IIS.

Пользователь получает результат обработки

Схематично весь процесс можно представить следующим образом:

Cервер приложений Internet Information Services (IIS)

Администраторам и разработчикам Web-приложений необходим надежный, легкоуправляемый, высокопроизводительный и защищенный Web-сервер. В Internet Information Services (IIS) 6.0 и Microsoft ® Windows ® Server 2003 появилось много новых возможностей, обеспечивающих надежность, доступность, управляемость, масштабируемость и безопасность сервера Web- приложений.

IIS 6.0 — ключевой компонент платформы приложений Windows Server 2003 — представляет собой интегрированный набор сервисов и средств, обеспечивающих разработку и развертывание высокопроизводительных Web-сайтов, Web-приложений и Web-сервисов.

Роль сервера приложений в семействе продуктов Windows Server 2003 сочетает в себе следующие серверные технологии:

1. Internet Information Services (IIS) 6.0 Информационные службы Интернета (IIS) 6.0. Они являются полноценным веб-сервером, оптимизированным для запуска веб-приложений и служб на узле.

2. Microsoft .NET Framework;


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

· общая языковая среда выполнения

· библиотека классов Microsoft .NET Framework.

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

Библиотека классов Microsoft .NET Framework — собрание повторно используемых объектов, которые можно применять при создании приложений ASP.NET.

3. ASP.NET это часть Microsoft .NET Framework. ASP.NET представляет собой откомпилированную среду, основанную на технологии .NET. Имеется возможность создавать приложения на любом совместимом с .NET языке, в том числе на Visual Basic .NET, C# и JScript .NET. Кроме того, возможности среды .NET Framework, в том числе управляемая общая языковая среда времени выполнения, безопасность типов и наследование, доступны любому приложению ASP.NET

4. ASP; Active Server Pages (ASP) — активные серверные страницы. Страницы ASP являются средой создания серверных сценариев для разработки динамических интерактивных приложений веб-серверов. Они позволяют разработчикам объединять нужным образом страницы в формате HTML, команды сценариев и компоненты COM для создания мощных и гибких веб-приложений.

5. UDDI-сервисы; UDDI (Universal Description, Discovery and Integration) — это промышленный стандарт публикации и поиска сведений о веб-службах. В некоторые продукты семейства Windows Server 2003 включаются службы UDDI, веб-службы, обеспечивающие использование возможностей UDDI на предприятиях или в организациях. Службы UDDI являются стандартной веб-службой XML. Они позволяют разработчикам предприятия эффективно изучать, открывать совместный доступ и повторно использовать веб-службы непосредственно через средства разработки. Они не включены в Windows Server 2003, Web Edition. Кроме того, Windows Server 2003, Standard Edition поддерживает только изолированную установку служб UDDI. Поддержка распределенной установки доступна в Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition. При изолированной установке служб UDDI компоненты веб-сервера UDDI и баз данных UDDI устанавливаются на один компьютер. При распределенной установке компоненты UDDI распределены по нескольким серверам.

6. COM+; расширение модели объектных компонентов (COM). COM+ основано на интегрированных службах и свойствах COM, облегчая разработчикам создание и использование компонентов программного обеспечения на любом языке и используя любые средства.

7. Microsoft Message Queuing (MSMQ). Сервер очередей сообщений Microsoft. Очередь сообщений создается для взаимодействия приложений в распределенной среде (на разных компьютерах). Особенность MSMQ в том, что компьютеры не обязательно должны быть одновременно в сети. То есть можно отправить сообщение, можно получить, а за всем этим следит сервер MSMQ.

Таким образом, сервер приложений позволяет разработчикам Web-приложений и администраторам осуществлять хостинг динамических приложений, например для управления базой данных приложений Microsoft ASP.NET, не надо устанавливать на сервере дополнительное программное обеспечение.

В Windows Server 2003 сервер приложений можно настроить двумя способами: через мастер Configure Your Server или из приложения Add/Remove Components.

Архитектура обработки запросов в IIS 6.0

Сложность кода Web-сайтов и приложений постоянно возрастает.

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

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

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

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

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

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

В IIS 6.0 заложены две новые концепции

1. пулы приложений (application pools)

2. рабочие процессы (worker processes).

Пулы приложений применяются для управления набором Web-сайтов и приложений. Каждый пул приложения соответствует одной очереди запросов в HTTP.sys и одному или более Windows-процессам, обрабатывающим эти запросы.

IIS 6.0 поддерживает до 2 000 пулов приложений.

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

То есть Интернет-провайдер (Internet Service Provider, ISP) может запускать Web-сайты и приложения одного клиента в одном пуле приложений, а Web-сайты второго клиента — в другом.

Пулы приложений отделяются друг от друга границами процессов в Windows Server 2003. Таким образом, приложения в одном пуле не влияют на приложения в другом; кроме того, запросы к приложениям нельзя перенаправлять из одного пула в другой.

Рабочий процесс обслуживает запросы к Web-сайтам и приложениям в пуле. Вся обработка Web-приложений, аутентификация и авторизация, выполняется новой библиотекой DLL Web – сервиса, которая загружается в один или несколько рабочих хост-процессов. Исполняемый файл рабочего процесса называется W3wp.exe.

В предыдущей версии IIS (IIS 5.0) один процесс, Inetinfo.exe, выполнял функции главного процесса Web-сервера. Он перенаправлял запросы к «внепроцессным» приложениям, размещенным в процессах DLLHost.exe.

IIS 6.0, напротив, состоит из двух новых компонентов:

1. Компонент WWW Service Administration and MonitoringДиспетчер пользовательского режима, управляющий работой сервера и следящий за выполнением кода приложения. Этот компонент не загружает и не исполняет код приложения. Другими словами компонент пользовательского режима, предназначенного для администрирования и мониторинга.

2. Стек HTTP режима ядра (HTTP.sys), который помещает в очередь и разбирает входящие HTTP-запросы, а также кэширует и возвращает контент сайта и приложения. HTTP.sys не загружает код приложения — он просто анализирует и перенаправляет запросы.

Таким образом, HTTP.sys в IIS принимает запросы и помещает их в очереди.

Каждая очередь запросов соответствует одному пулу приложений.

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

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

1. перезапуска процесса, который начнет принимать запросы,

2. исчерпания очередей,

3. отсутствия места в очередях

4. остановки администратором самого Web-сервиса.

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

Такая архитектура позволяет IIS 6.0 отделять операции Web-сервера от выполнения кода Web-сайта и приложения без ухудшения производительности.

Настройка сервера и управление рабочим процессом

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

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

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

Все предварительные действия выполняются до того, как HTTP.sys приступает к перенаправлению запросов индивидуальным процессам.

По мере добавления новых приложений и их пулов Web-сервис настраивает HTTP.sys на прием новых адресов, создает новые очереди запросов для новых пулов приложений и указывает, куда перенаправлять новые URL. Для динамического изменения информации о маршрутизации перезапуск сервиса не требуется.

В роли управляющего рабочим процессом компонент WWW Service Administration и Monitoring отвечает за управление жизненным циклом рабочего процесса, обрабатывающего запросы.

Это подразумевает принятие решений о запуске, использовании и перезапуске рабочего процесса в случае, если он не может обслуживать дальнейшие запросы (заблокирован). Кроме того, он ведет мониторинг рабочего процесса и способен обнаружить его неожиданное завершение.

Режим изоляции рабочего процесса

IIS 6.0 предоставляет новый режим изоляции приложения для управления обработкой Web-сайтов и приложений — режим изоляции рабочего процесса.

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

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

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

Первым делом HTTP.sys отправляет запросы, адресованные к Web-сайтам и приложениям, соответствующим очередям пулов приложений.

Затем рабочий процесс, обслуживающий пул приложений, извлекает запросы напрямую из очереди приложений в HTTP.sys. Такая модель позволяет избавиться от лишних переключений процессов, возникающих при отправке запросов внепроцессному DLLHost.exe и обратно (как в IIS 4.0 и 5.0), что увеличивает производительность.

Важно отметить, что в IIS 6.0 нет понятия внутрипроцессного приложения. Все необходимые приложению сервисы периода выполнения в равной степени доступны в любом пуле приложений.

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

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

Дополнительное преимущество — возможность задействовать другие сервисы операционной системы, доступные на уровне процесса [например управление распределением процессорного времени (CPU throttling)] для пулов приложений. Кроме того, архитектура Windows Server 2003 поддерживает гораздо больше параллельных процессов, чем в предыдущих операционных системах.

Режим изоляции рабочего процесса не дает одному приложению или сайту остановить другие приложения.

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

включение/выключение сайта или приложения (независимо от остальных работающих сайтов или приложений),

· изменение используемого приложением компонента,

· наблюдение за счетчиками производительности,

· регулирование ресурсов, выделяемых приложению.

Режим изоляции рабочего процесса в IIS 6.0 имеет следующие особенности.

1. Кэширование в режиме ядра.. В IIS 6.0 кэширование в режиме ядра осуществляется как в режиме изоляции рабочего процесса, так и в режиме изоляции IIS 5.0 (см. ниже). В качестве единой точки приема всех входящих (серверных) HTTP-запросов HTTP.sys создает высокопроизводительный канал связи для серверных HTTP-приложений и обеспечивает общее управление соединениями, регулирование полосы пропускания и протоколирование на стороне Web-сервера. IIS 6.0 основан на HTTP.sys и специально настроен на увеличение производительности Web-сервера. Кроме того, в некоторых случаях HTTP.sys напрямую обрабатывает запросы в ядре. Как статический, так и динамический контент Web-сайтов и приложений может помещаться в кэш HTTP.sys для уменьшения времени ответа.

2. Четкое разделение между пользовательским кодом и сервером.Весь пользовательский код обрабатывается рабочими процессами, полностью изолированными от ядра Web-сервера. Это важное усовершенствование по сравнению с IIS 5.0, так как ISAPI зачастую выполняются внутрипроцессно в ядре Web-сервера. Если ISAPI, загруженный в рабочий процесс, вызывает сбой или нарушение доступа к памяти, останавливается лишь рабочий процесс, выполняющий ISAPI. Тем временем сервис WWW создает новый рабочий процесс, заменяющий рухнувший. На остальные рабочие процессы это не оказывает никакого влияния.


3. Множественные пулы приложений.В IIS 5.0 приложения можно объединять во внепроцессный пул, но только в один, который выполняется в среде DLLHost.exe. Когда IIS 6.0 работает в режиме изоляции процессов, администраторы могут создать до 2 000 пулов приложений, причем каждый из них можно конфигурировать раздельно.

4. Улучшенная поддержка распределителей нагрузки. Благодаря пулам приложений IIS 6.0 поддерживает физическое разделение приложений. IIS 6.0 способен автоматически взаимодействовать с распределителями нагрузки (load balancers) или с коммутаторами для блокирования трафика к проблемному приложению, параллельно продолжая принимать запросы к другим приложениям. В IIS 6.0 также встроена модель расширения, позволяющая генерировать события и команды при обнаружении сбоя в конкретном приложении. Такая конфигурация позволят распределителям нагрузки и коммутаторам автоматически блокировать трафик к проблемным приложениям, не препятствуя запросам к работающим.

5. Web-сады (Web gardens).На обслуживание запросов, адресованных одному пулу приложений, можно настроить несколько рабочих процессов. По умолчанию каждому пулу соответствует один рабочий процесс. Однако пул можно настроить так, чтобы ему соответствовал набор из N эквивалентных рабочих процессов, разделяющих нагрузку. Такая конфигурация называется Web-садом. HTTP.sys распределяет запросы между рабочими процессами в группе. Распределение запросов основано на принципе карусели. Преимущества Web-садов в том, что, если один рабочий процесс замедляется, например, когда подсистема выполнения сценариев перестает отвечать, прием и обработка запросов продолжается остальными рабочими процессами.

6. Слежение за состоянием. Компонент WWW Service Administration and Monitoring следит за состоянием приложений, периодически проводя тестовый опрос рабочих процессов, чтобы выяснить, не заблокированы ли они. В случае блокировки рабочего процесса сервис WWW завершает рабочий процесс и создает вместо него новый. Сервис WWW поддерживает коммуникационный канал с каждым рабочим процессом и всегда в состоянии определить сбой в рабочем процессе по обрыву канала.

7. Привязка к процессорам (processor affinity). Рабочие процессы можно привязать к конкретным процессорам, чтобы увеличить частоту попаданий в кэш процессора (уровня L1 или L2). Реализация привязки к процессорам приводит к тому, что рабочие процессы IIS 6.0 выполняются на конкретных процессорах, и эта привязка распространяется на все рабочие процессы, обслуживающие Web-сайты и приложения в каком-либо пуле. Привязку к процессорам можно использовать в сочетании с Web-садами, выполняемым на многопроцессорных компьютерах, где под конкретные пулы приложений выделены кластеры процессоров.

8. Сопоставление сайтов и приложений с пулами приложений. В IIS 6.0, как и в IIS 5.0, приложения определяются как пространства. Сайты по умолчанию считаются простыми приложениями, в которых пространство имен сконфигурировано как приложение. Пул приложений можно настроить на обслуживание от одного Web-приложения до множества приложений и сайтов. Чтобы поместить приложение в пул, следует использовать IIS Manager или напрямую модифицировать метабазу.

9. Запуск по требованию. Пулы приложений позволяют запускать процессы, обслуживающие группу пространства имен по требованию, т. е. при первом запросе к URL, который является частью этого пространства имен. Компонент WWW Service Administration and Monitoring выполняет запуск процесса по требованию и в целом контролирует жизненный цикл рабочих процессов.

10. Время ожидания в простое. Пул приложений можно настроить на остановку собственных рабочих процессов, если они простаивают в течение определенного периода. Это нужно для освобождения неиспользуемых ресурсов. При необходимости для данного пула приложений запускаются дополнительные рабочие процессы (см. далее «Запуск по требованию»).

11. Быстрая защита от сбоев. При сбое рабочий процесс обрывает коммуникационный канал с компонентом WWW Service Administration and Monitoring. Последний обнаруживает это и принимает меры, обычно включающие запись события в журнал и перезапуск рабочего процесса. Кроме того, IIS 6.0 можно настроить на автоматическую блокировку рабочего процесса, если в пуле приложений возникает определенное число сбоев за заданный период. Такое поведение называется быстрой защитой от сбоев (rapid-fail protection). Быстрая защита от сбоев переводит пул приложений в состояние «не обслуживается», и HTTP.sys немедленно возвращает сообщение 503 (Service Unavailable) на любые запросы к частям этого пространства имен, в том числе на запросы, уже помещенные в очередь этого пула приложений.

Илон Маск рекомендует:  Asp компонент counters

12. Отбрасывание (orphaning) рабочих процессов.Режим изоляции рабочего процесса можно настроить на отбрасывание рабочих процессов, которые считаются зависшими. Например, если рабочий процесс не отвечает на тестовые опросы в течении определенного периода, сервис WWW обычно завершает его и запускает новый. А если включено отбрасывание, он оставляет зависший процесс в памяти и запускает новый. Кроме того, сервис WWW можно настроить на выполнение команды над рабочим процессом (например на подключение отладчика) при его отбрасывании.

13. Повторное использование рабочих процессов.Сейчас многие организации страдают от проблем, связанных с тем, что Web-приложения вызывают утечки памяти, плохо написаны или содержат непонятные ошибки. Это вынуждает администраторов периодически перезапускать Web-серверы. В предыдущих версиях IIS способа перезапустить Web-сайт, не прерывая работу всего сервера, не было. Режим изоляции рабочего процесса можно настроить на периодический перезапуск рабочих процессов в пуле приложения для борьбы со сбойными приложениями. Рабочие процессы можно настроить на перезапуск в соответствии со следующими критериями: истекшим временем, количеством обслуженных запросов, временем суток, использованием виртуальной и физической памяти, а также по требованию. Когда рабочий процесс считает необходимым выполнить перезапуск, он уведомляет WWW-сервис, который в свою очередь дает команду на завершение существующим рабочим процессам и выделяет заданное время на обработку оставшихся запросов. Одновременно сервис WWW создает замещающий рабочий процесс для той же группы пространства имен, и новый рабочий процесс запускается до завершения работы старого. Это предотвращает перебои в обслуживании. Старый рабочий процесс поддерживает связь с HTTP.sys для завершения обработки своих запросов, а затем либо нормально завершает работу, либо его работа завершается извне, если он не остановился по истечении заданного периода.

14. Режим изоляции IIS 5.0 Некоторые приложения не совместимы с режимом изоляции рабочего процесса IIS 6.0, например приложения-фильтры, читающие необработанные данные, или приложения, полагающиеся на выполнение в Inetinfo.exe или DLLHost.exe. Поэтому IIS 6.0 способен работать в другом режиме изоляции, который называется режимом изоляции IIS 5.0 и обеспечивает совместимость. Использование этого режима напоминает работу с самим IIS 5.0, так как в нем присутствуют те же основные процессы пользовательского режима. В частности, есть те же методы изоляции приложений (низкий, средний в пуле и высокий), а Inetinfo.exe — по-прежнему главный процесс, через который проходят все запросы.

Система безопасности IIS

Система безопасности IIS использует преимущества стандартов безопасности Интернет, поддерживаемых Windows.

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

Secure Sockets Layer (SSL). Протоколы безопасности SSL широко используются Web-браузерами и серверами для аутентификации, конфиденциальности и целостности сообщений. При помощи функций безопасности SSL можно проверить целостность содержания Web-сервера, реквизиты пользователей и шифровать передаваемые по сети сообщения.

Transport Layer Security (TLS). TLS основан на SSL. Он помогает выполнять безопасную аутентификацию пользователей, а независимым программистам позволяет создавать поддерживающий TLS код, способный обмениваться зашифрованной информацией с другим процессом без ознакомления с кодом, созданным другим программистом. Кроме того, TLS является каркасом для построения новых методов шифрования с открытым ключом и шифрования больших объемов данных. TLS служит и для повышения производительности, уменьшая сетевой трафик и предлагая схему кэширования сессий, позволяющую сократить количество соединений, устанавливаемых «с нуля».

PKCS #7. Этот протокол описывает формат зашифрованных данных, например цифровых подписей или цифровых конвертов.

PKCS #10. Этот протокол описывает формат посылаемых сертификационным центрам (Certificate Authority, CA) запросов на получение сертификата.

Обычная проверка подлинности. Обычная аутентификация — стандартный метод сбора информации об именах пользователей и паролях. Она посылает пароли по сети в формате Base64 Encoded. К ее достоинствам можно отнести то, что она является частью спецификации HTTP 1.0 и поэтому поддерживается большинством браузеров. Однако обычная аутентификация имеет существенный минус — использующие ее Web-браузеры пересылают пароли в незашифрованном виде.

Краткая проверка подлинности. Она обладает теми же возможностями, что и обычная но передает аутентификационные сведения иначе.

Они проходят через одношаговый процесс — хеширование (hashing). Результат этого процесса называется хешем (hash), или выборкой сообщения (message digest). Исходный текст не может быть расшифрован из хеша. Перед хешированием к паролю добавляется дополнительная информация генерируемая сервером, поэтому никто не сможет перехватить хеш пароля и с его помощью выдавать себя за истинного клиента. Краткая аутентификация основана на методологии общего секретного пароля. Она структурирована для использования несколькими прокси-серверами. Краткая аутентификация поддерживается не всеми обозревателями. Если не поддерживающий краткую аутентификацию браузер пошлет запрос на сервер, требующий именно этот способ аутентификации, сервер не будет обрабатывать запрос и сообщит клиенту об ошибке.

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

IIS поддерживает для служб HTTP и FTP:

1. анонимную проверку подлинности HTTP и FTP;

2. обычную проверку подлинностиHTTP и FTP;

3. краткую проверку подлинности для доменов Windows 2000 и браузеров, поддерживаю щих этот способ аутентификации, реализованныйв HTTP I.I;

4. интегрированную проверку подлинности Windows (толькоHTTP).

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.

Отладка приложения ASP.NET, размещенного на IIS: прикрепление процесса и выяснение, какой процесс прикрепить

Written on 03 Июля 2013 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

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

Оглавление

  • Обзор

  • Отладка ASP . NET по сравнению с отладкой IIS
  • Что такое рабочий процесс?
  • Пул приложений
    • Что такое пул приложений?
    • Стандартный пул приложений
    • Создание собственного пула приложений
    • Назначение сайта пулу приложений
  • Как начать?
  • Какой процесс прикрепить?
  • Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов.
    • Получение списка выполняющихся рабочих процессов
    • Прикрепление нужного процесса
  • Вывод

Обзор

Обычно веб-приложение Asp.Net отлаживается из Visual Studio. Visual Studio имеет собственный механизм ASP.Net, способный запускать и отлаживать веб-сайты внутри visual studio. Но если ваш сайт размещен на IIS, и вы хотите отладить этот сайт, как вы будете его отлаживать? При размещении сайтов на IIS worker process(w3wp.exe) используется для запуска веб-приложения. Надо прикрепить конкретный процесс в Visual Studio, чтобы отлаживать приложение. Данная статья описывает общую идею отладки приложения с помощью прикрепленного процесса. Она также рассматривает рабочий процесс, пул приложений и выбор конкретного процесса, если на IIS выполняется несколько рабочих процессов, с помощью iisapp.vbs. Надеемся, вам понравится эта статья, и вы дадите ценные советы и отзывы.

Отладка ASP.NET по сравнению с отладкой IIS

Visual studio имеет встроенный механизм отладки, отлаживающий код при запуске приложения из Visual Studio. Если при разработке сайтов надо отладить код, ставятся точки останова и производится отладка. [Примечание: В этой статье не описан способ установки режима отладки]. При запуске приложения выполнение кода останавливается, когда приходит определенная точка останова. Это очень просто, поскольку, когда приложение ASP.NET запускается из Visual studio, его контролирует механизм Asp.Net, встроенный в Visual Studio. Если вы хотите проверить, какой процесс запускается для отладки, запустите веб-приложение из Visual Studio и получите такое всплывающее уведомление, как ниже:

Рисунок. Отображение всплывающего уведомления при запуске отладки из Visual Studio

Уведомление показывает, что процесс запускается для выполнения приложения ASP.NET. Дважды щелкните по иконке. Появится всплывающее окно и покажет характеристики.

Рисунок. Характеристики процесса сервера разработки

За выполняющимся процессом находится «WebDev.WebServer.Exe». При нажатии F5 для запуска этот процесс начинает выполнять приложение Asp.Net. Если вы хотите запустить приложение из командной строки, выполните следующие шаги.

Шаги:
1. Открыть командную строку Visual Studio
2. Запустить Webdev.WebServer

Появится следующий экран. Смотрите раздел примеров.

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

Что такое рабочий процесс?

Рабочий процесс (w3wp.exe) запускает приложение ASP.Net в IIS. Вся функциональность ASP.Net выполняется внутри рабочего процесса. Когда на сервер приходит запрос от клиента, рабочий процесс отвечает за генерацию запроса и ответа. Он также хранит данные сессии InProc. При перезапуске рабочего процесса теряется состояние рабочего процесса. Дополнительную информацию сморите в статье Низкоуровневое рассмотрение архитектуры ASP.NET

Пул приложений

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

Стандартный пул приложений

Имя стандартного приложения IIS 6.0 — «DefaultAppPool». После размещения сайта на IIS при проверке свойств Виртуальной директории вы сможете увидеть, что:
1. Start(пуск) – Run(выполнить) — Inetmgr
2. Развернуть «DefaultWebSites» или Другие веб-сайты, где вы создали Виртуальную директорию
3. Щелкнуть правой кнопкой мыши по Виртуальная директория
4. Щелкнуть по Свойства

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

Чтобы проверить список всех пулов приложений в IIS, разверните Узел пула приложений на сервере IIS.

Рисунок. Стандартный пул приложений

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

Создание и назначение пула приложений

Откройте консоль IIS, щелкните правой кнопкой мыши по папке пула приложений > Создать New(новый)

Введите Идентификатор пула приложений и нажмите Ok.

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

Итак, эти веб-сайты будут запускаться независимо в StateServerAppPool. Следовательно, любая проблема, связанная с другим приложением, не влияет на ваше приложение. Это основные преимущества создания пула приложений отдельно.

Как начать?

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

Был создан один веб-сайт под именем sampleWebSite и размещен на локальном IIS. Ниже показан вывод страницы по умолчанию.

Рисунок. Пример веб-сайта

Какой процесс прикрепить?

Как уже было сказано, имя процесса — w3wp.exe, следовательно, можно проверить его из менеджера задач, выполняется рабочий процесс или нет

Рисунок. Менеджер задач показывает выполняющийся процесс

Теперь прикрепим процесс. Перейдите в Отладка > Прикрепиться к процессу

Рисунок. Открыть окно прикрепления процесса

После нажатия на Прикрепиться к процессу появится следующий экран,

Рисунок. Выполняется один рабочий процесс

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

Рисунок: 1) Процесс успешно прикреплен 2) Процесс не прикреплен

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

Теперь при нажатии на кнопку отладки веб-страницы выполнение кода остановится в точке останова.

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

Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов?

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

Мы имеем 3 пула приложений в IIS:
• Стандартный пул приложений
• Обобщенный пул приложений
• Пул приложений сервера состояний

Сейчас SampleWebSite связан с defaultAppPool, и мы хотим прикрепить процесс для отладки SampleWebSite. Выполните такой же шаг для открытия окон прикрепления процесса

Рисунок. Список рабочих процессов

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

Рисунок. Процесс не прикрепился правильно

Получение списка выполняющихся рабочих процессов

Ниже даны советы по решению указанной проблемы.
• Пуск > Выполнить > Cmd
• Перейти в Windows > System32
• Выполнить cscript iisapp.vbs и ждать вывода.

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

Рисунок. Список выполняющихся рабочих процессов с PID и именем пула приложений

Прикрепление правильного процесса

Отсюда вы можете легко определить имя пула приложений и идентификатор процесса. Снова вернемся в VS > Прикрепить процесс. Теперь вы знаете, что идентификатор процесса для стандартного пула приложений равен 1772, следовательно, Прикрепить процесс.

Рисунок. Прикрепить процесс для отладки

Теперь наслаждайтесь отладкой.

Рисунок. Точка останова готова

Вывод

Иногда приходится отлаживать приложение, размещенное на IIS. Для этого надо прикрепить выполняющийся рабочий процесс к коду Visual Studio. Если на сервере IIS выполняется несколько рабочих процессов, мы можем определить правильный рабочий процесс с помощью команды cscript iisapp.vbs. Надеемся, статья поможет новичкам, испытывающим затруднения с отладкой приложения, размещенного на IIS.

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


Трактат о производительности MS CRM. Книга III: настройка IIS

На примере IIS 7.x … ��

Обновление КЭШа

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

В результате элементы Microsoft Dynamics CRM будут загружаться во временные файлы и втечении 15 дней не будет проверятся налитчие новых версий.
Откойте менеджер IIS – щелкните по сайту Microsoft Dynamics CRM – в представлении Features View откройте HTTP Response Headers – на панели Actions (прилеплена к правой стороне окна) щелкните по Set Common Headers – и задайте значение для Expire.

Примечание: изменения вступят в силу на клиентских компьютерах после истечения срока текущих настроек.

IIS7 Output Caching

Веб-содержимое может быть разделено на две категории: статическое информационное наполнение и динамическое информационное наполнение. Статическое информационное наполнение не изменяется от запроса к запросу. Примером статического информационного наполнения являются файлы HTML, JPG или GIF.
Динамическое же информационное наполнение изменяется с каждым запросом. Например, ASP.NET или PHP страницы.

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

Возможность IIS 7.0 Output Caching, как раз и предназначается для полудинамического контекта (но также может кэшировать и статический контент). Она позволяет Вам кэшировать отдельные (статические) копии ответов динамических запросов, основываясь на строке запроса.

Что для этого нужно…

  • Откройте IIS, выберите сайт Microsoft Dynamics CRM;
  • В представлении Feature View дважды щелкните по Output Caching;
  • На панели Action, нажмите Edit Feature settings, удостоверьтесь, что и кэш и кэш ядра включены и нажимите OK;Теперь нужно добавить правила кэширования для сайта, которые мы запустим на Корневом уровне.
  • Все еще в корне веб-сайта в разделе Output Caching, нажмите Add и задайте такие параметры:
    • File Name Extension: bmp
    • Поставьте галку: Kernel Mode Caching
    • File Cache Monitoring: Using file change notifications
    • Нажмите OK и добавьте такие же правила кэширования для расширений css, gif, htc, js и png файлов.

    Отключение логов IIS

    Ведение логов IIS занимает ресурсы процессора, дисков и памяти, что не очень позитивно сказвыается на производительности. Поэтому их включение целесообразно только для отладки приложений или устранения каких-либо проблем. Чтобы отключить ведение логов сделайте следующее:
    В IIS Manager выделите сайте CRM – в представлении Feature View дважды щелкните кнопкой по Logging – щелкните по Disable, чтобы отключить логи для сайта.

    HTTP Compression

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

    • Щедкните правой кнопкой мыши по руту в IIS Manager’е — Properties — вкладка Service – далее Вы можете выбрать две опции:
      • Compress application files – включает сжатие динамических страниц, в которые по умолчанию входят asp, dll, и exe.
      • Compress static files – включает сжатие htm, html, и txt файлов (по умолчанию);

    В IIS Manager выделите сайте CRM – в представлении Feature View дважды щелкните кнопкой по Compression – отметьте галками Enable dynamic content compression и/или Enable static content compression для включения динамического (по умолчанию входят файлы asp, dll и exe) и/или статического (по умолчанию входят файлы htm, html и txt) контента сайта.

    Вы можете изменить список типов файлов, включенных в сжатие, откройте на редактирование файл C:\Windows\System32\inetsrv\config\applicationHost.config. Найдите секцию httpCompression и добавьте/удалите типы файлов подлежащие сжатию.

    Напрмер, чтобы включить сжатие файлов Word и Excel, добавьте такие строки в раздел :

    Чтобы изменения вступили в силу, необходимо перезапустить IIS.

    Web gardens (Web-сады)

    В IIS 6.0 Был добавлен новый режим обработки запросов, называемый режимом изоляции рабочих процессов (англ. worker process isolation mode). В этом режиме все веб-приложения, обслуживаемые сервером, работают в разных процессах, что повышает стабильность и безопасность системы. Кроме того, для приёма запросов HTTP был создан новый драйвер http.sys, который работает в режиме ядра, что ускоряет обработку каждого запроса.

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

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

    Чтобы задействовать Web garden для CRM: В IIS менеджере выделите узел Application Pools — выделите пул CRMAppPool — щелкните Advance Setting — установите в секции Process Model необходимое значение Maximum Worker Process.

    TTL кэша IIS

    IIS кэшируют любые запрошенные объекты. У каждого объекта в пределах кэша есть время «жизни» (TTL) – время, в течение которого объект должен находиться в кэше и из которого IIS его достанет и выдаст, в случаи запроса. Что в результате значительно ускоряет работу веб-сервера. По умолчанию, значение TTL установлено в 30 секунд. Т.е. если объект в кэше не использовался в течение прошлых 30 секунд, то он удаляется.

    И тут у нас опять палка о двух концах: 30 секунд это много или мало? Если все страницы на Вашем сайте являются динамичными, то IIS действительно не извлечет большую выгоду из кэширования. Соответсвенно уменшив этот параметр Вы могли бы освободить память под другие нужды. С другой стороны, если у Вашего сервера много свободной памяти, и куча статичных страниц, то Вы можете улучшить эффективность работы, увеличив TTL.

    Чтобы изменить этот параметр откройте реестр. Далее в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters добавьте новый DWORD-ключ с именем ObjectCacheTTL и значением от 0 до 4 294 967 295 (это в секундах, где 0 – полное отсутствие кэширования).

    Трассировка и дебаггинг

    Для повышения производительности также можно отключить трассировку и дебаггинг (если они у Вас включены), с помощью конфигурациооных файлов machine.config (расположен в папке .Net Framework’а под которым выполняется пул приложений, например: C:\Windows\Microsoft.NET\Framework\vXXXX\Config\machine.config) и/или Web.config (находится внутри папки сайта CRM):

    Другие параметры

    Документ Optimizing and Maintaining Microsoft Dynamics CRM 4.0 также рекомендует использовать такие параметры для наcтройки IIS:

    Параметр Значение
    maxWorkerThreads 100
    maxIoThreads 100
    maxconnection 12*n (где n это число процессоров)
    minFreeThreads 88*n
    minLocalRequestFreeThreads 76*n
    minWorkerThreads 50

    Настраиваются эти параметры в файле C:\WINDOWS\Microsoft.NET\Framework\vXXXX\CONFIG\machine.config

    Примечание: Еесли у Вас есть hyperthreading, Вы должны использовать число логических центральных процессоров вместо физических. Т.е., если у Вас сервер с четырьмя процессорами, то значение N в формулах будет 8 вместо 4.

    Расширенные возможности управления IIS 7.0 с помощью IIS Administration Pack

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

    В состав Administration Pack входит набор модулей, расширяющих функциональность оболочки Internet Information Services Manager:

    • Configuration Editor – редактор конфигурации веб-приложения
    • .NET Authorization Rules – модуль управления правилами авторизации для приложения
    • .NET Error Pages – инструмент конфигурирования страниц, отображаемых в случае возникновения ошибок
    • FastCGI Settings – редактор конфигурации обработчиков CGI приложений, таких как PHP
    • Request Filtering – модуль фильтрации запросов к серверу
    • IIS Reports – инструмент создания графических отчетов по логам сервера

    Configuration Editor

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

    Сам редактор представляет собой таблицу со списком свойств (атрибутов в XML файле конфигурации) в виде таблицы. Для свойств присутствует валидация на основании типа значения, поэтому можно не бояться случайно ввести текст там, где ожидается число.

    Что очень удобно, внутри редактора конфигурации есть список всех возможных параметров конфигурации.

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

    Что еще более удобно, инструмент позволяет экспортировать C#, JavaScript код или набор инструкций командной строки для автоматизации применения настроек блокировки на других серверах.

    .NET Authorization Rules и .NET Error Pages

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

    Модуль авторизации предлагает возможные варианты правил для разрешения или запрета доступа.

    А модуль конфигурирования «ошибочных» страниц позволяет связать адрес страницы с HTTP кодом ошибки.

    FastCGI Settings

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

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

    Request Filtering

    Модуль Request Filtering позволяет гибко настроить исключения для обрабатываемых запросов.

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

    Помимо этого можно настроить общие ограничения на длину запроса и размер возвращаемого ответа.

    IIS Reports

    Инструмент IIS Reports позволяет оперативно получать удобную статистику по работе веб-сервера.

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

    Инструмент поддерживает графическое представление в виде гистограммы и круговой диаграммы, а также экспорт отчетов в HTML.

    Все вместе эти инструменты позволяют упростить управление веб-сервером IIS.

    ИТ База знаний

    ShareIT — поделись знаниями!

    Полезно

    Узнать IP — адрес компьютера в интернете


    Онлайн генератор устойчивых паролей

    Онлайн калькулятор подсетей

    Калькулятор инсталляции IP — АТС Asterisk

    Руководство администратора FreePBX на русском языке

    Руководство администратора Cisco UCM/CME на русском языке

    Серверные решения

    Телефония

    FreePBX и Asterisk

    Настройка программных телефонов

    Корпоративные сети

    Похожие статьи

    Установка MySQL Server на CentOS 7

    Как включить Hyper-V в Windows

    Установка CentOS 7 Minimal

    Самое интересное про Guest Additions в VirtualBox

    Apache или IIS – сравнение и преимущества

    Про веб — сервера

    Если вы, или ваша организация намереваетесь создать Web – сервис, будь то сайт или приложение, то так или иначе вы обратите внимание на наиболее популярные на рынке платформы для создания web – серверов – Apache или Internet Information Services (IIS), которые занимают около 70% от всей доли интернета.

    Многие сравнивают противостояние этих двух платформ как соперничество между Microsoft и Linux. В данной статье мы беспристрастно и объективно рассмотрим плюсы и минусы этих платформ.

    Apache

    Apache HTTP web – сервер – полное название платформы, распространяемой организацией Apache Software Foundation как открытое программное решение или проще говоря «open-source». Программное обеспечение сервера распространяется абсолютно бесплатно и его лицензия позволяет конечному пользователю редактировать исходный код, чтобы адаптировать Apache под свои нужды, а так же, внести вклад в будущее развитие серверной платформы.

    Веб – сервер Apache может работать на всех популярных операционных системах, но чаще всего он используется в рамках Linux. Именно в паре с СУБД MySQL и PHP – скриптами образуется известный комплекс программного обеспечения LAMP Web – сервер (Linux, Apache, MySQL, PHP), который повсеместно используется в сети интернет.

    В рамках исследования Netcraft, проводимого в феврале 2014 года, web – сервер Apache занимал 42% рынка. Однако стоит отметить, что в том же июне 2013 года этот показатель составлял 54% и 59% в 2010 году. Это связано с улучшением позиций основного конкурента IIS и ростом позиций Nginx.

    С точки зрения функционала, Apache имеет впечатляющие характеристики. Многие функции реализуются как совместимые модули, расширяющие базовый функционал, диапазон которых варьируется от поддержки языков программирования до обеспечения различных схем аутентификации. Например, это могут быть языки Perl или Python. Модули аутентификации включают в себя элементы управления доступом к различным директориям сервера, пароль, установление подлинности и так далее. Многие другие функции, такие как Secure Sockets Layer (SSL) или TLS (Transport Layer Security) так же обеспечивается модульной системой. Помимо этого, Apache поддерживает возможность развернуть несколько web – сайтов, или графических интерфейсов приложений. Веб – сервер сжимает страницы, чтобы уменьшить их размер, что обеспечивает высокую скорость их загрузки. Наряду с высоким показателем безопасности, это является конкурентной чертой Apache.

    Выделим два основных недостатка Apache HTTP web – сервера:

    • Перенасыщенность функционалом: Еще раз стоит подчеркнуть, что Apache действительно чрезвычайно богат на функции, возможности и инструментарий. Но, к сожалению, в рамках типовой инсталляции пользователь задействует только 10 % от этих функций.
    • С точки зрения архитектуры, Apache, работает по модели «процессов». Это означает, что для каждого соединения Apache выделяет отдельную «коннекцию», или другими словами поток данных, что вызывает значительную загрузку. Конкуренты, а именно асинхронные платформы и сервера работающие по модели «событий», имеют преимущество обработки нескольких процессов одновременно в рамках одной транзакции.

    Internet Information Services (IIS) это веб – сервер разработки компании Microsoft и занимает второе место на рынке вслед за Apache. Платформа IIS будет работать только с Windows и поставляется в комплекте с этой операционной системы. В отличие от Apache, где основную поддержку продукта предоставляет сообщество разработчиков, IIS официально поддерживается компанией Microsoft. Разработка этого продукта не так стремительна по сравнению с Apache, но как было сказано выше, одним из главных конкурентных преимуществ IIS является официальная поддержка компании Microsoft, что очень важно для крупного бизнеса. Многие специалисты в области ИТ признают IIS одним из немногих коммерческих продуктов, который по настоящему может быть конкурентом «open-source» решению.

    Постоянная доработка безопасности, производительности и удобства администрирования позволили увеличить долю присутствия на рынке IIS с 21% в 2010 году до 32% в феврале 2014 (ранее указанное исследование компании Netcraft). Самые большие продвижения были сделаны с точки зрения безопасности. Версия IIS 6.0 была уязвима к атакам: известный вирус Code Red, который заменял содержимое web – сайта на баннер об авторах вируса. Важно отметить, что многие уязвимости проявляются на уровне операционной системы.

    Как и Apache, IIS использует различные расширения для внедрения дополнительного функционала. Например, работа с файлами по FTP, маршрутизация с помощью Application Request Routing (ARR), который позволяет вести балансировку нагрузки и повышать отказоустойчивость, различные медиа – компоненты, аудио, видео, динамическое изменение URL и прочие. Веб – сервер IIS предлагает более высокую совместимость с программной платформой .NET Framework и ASPX (Active Server Pages) чем Apache. Важно, что в IIS поддерживаются такие функции как мониторинг, отслеживание запросов в режиме реального времени. Конечно, IIS можно назвать «условно» бесплатным, так как распространяется он в комплекте с Microsoft Windows Server.

    С точки зрения производительности, IIS уступает Apache, в виду архитектурной особенности и строгой работы на Windows.

    Подведем итог

    И IIS и Apache имеют свои плюсы и минусы. Определиться с web – сервером поможет учет следующих факторов: Сервер IIS должен быть приобретен в комплекте с Windows, Apache не имеет официальной технической поддержки, но имеет высокие показатели безопасности, IIS отлично совместим с .NET и так далее. В таблице ниже приведены некоторые сравнительные характеристики:

    Опция Apache IIS
    Поддерживаемая ОС Windows, Linux, Unix, Mac OS Windows
    Техническая поддержка Сообщество Корпоративная
    Стоимость Полностью бесплатно Покупается в комплекте с Windows
    Разработка «open-source» Проприетарное решение
    Безопасность Хорошо Отлично
    Производительность Хорошо Хорошо
    Рынок 42% 32%
    • WEB сервер Apache
    • IIS
    • 5895
    • 83

    Полезна ли Вам эта статья?

    Пожалуйста, расскажите почему?

    Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

    Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

    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
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL