Iis общие сведения о метабазе

Содержание

IIS: Как получить Metabase путь?

Я пытаюсь получить список типов mime, известных серверу IIS (который вы можете видеть, и мне ответил 2 года назад). Вложенный ответ:

Вы получаете идею. Все согласны с тем, что вы используете магический путь iis://localhost/mimemap. И это отлично работает, за исключением тех случаев, когда этого не происходит.

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

Здесь есть два ключа:

  • Он называет iis://localhost/mimemap путь метабазы ​​. Что звучит для меня так, как будто это своего рода «путь» к «метабазе».
  • Он говорит, что путь к метабазе может быть чем-то другим; и он дает пример того, как это может быть.

Прямо сейчас я и вся планета жестко кодируют » MetabasePath» как

Что должно быть на самом деле? Что должен делать код для создания действительного MetabasePath?

Примечание. Я не получаю ошибку отказа в доступе, ошибка такая же, когда у вас есть неверный MetabasePath, например. iis://localhost/SoTiredOfThis

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

Часть IIS: также известна как прозвище на языке OLE.

Если вы откроете файл метабазы ​​IIS6 ( C:\Windows\System32\inetsrv\metabase.xml ), вы увидите большой «blob» XML. Это фактически сглаженная древовидная структура.

Пути в метабазе представлены атрибутами Location .

Прозвище IIS://localhost отображает путь Location /LM , который фактически является корнем дерева.

Прозвище IIS://Localhost/mimemap отображается на путь Location /LM/MimeMap .

Если ваш код обращается к метабазе на удаленных компьютерах, вместо указания IIS://localhost/[path] следует указать IIS://[RemoteMachineName]/[path] . Это то, что комментирует Крис Кроуз.

IIS://Localhost/mimemap также является основным типом списка Mime. Все сайты наследуют этот список (метабаза IIS в значительной степени зависит от унаследованных свойств).

Если вы хотите переопределить типы Mime для определенного сайта, вы должны изменить:

Полезно открыть файл метабазы ​​IIS и поработать, чтобы понять, что происходит под капотом.

Update:

Чтобы ответить на вопрос о том, почему вы можете создать объект DirectoryEntry , где путь недействителен, DirectoryEntry — это объект оболочки общего назначения, используемый для привязки к различным типам поставщиков ADSI, таких как IIS, LDAP и WinNT. Это позволяет создавать объекты DirectoryEntry , где не обязательно должен быть соответствующий объект по указанному пути. Некоторым операциям провайдера ADSI может потребоваться эта возможность.

Существует статический метод на DirectoryEntry , называемый Exists , который вы можете использовать для проверки существования объектов. Например:

IIS: How to get the Metabase path?

i’m trying to get the list of mime types known to an IIS server (which you can see was asked and and answered by me 2 years ago). The copy-pasted answer involves:

You get the idea. Everyone agrees that you use a magical path iis://localhost/mimemap. And this works great, except for the times when it doesn’t.

The only clue i can find as to why it fails, is from an IIS MVP, Chris Crowe’s, blog:

There are two clues here:

  1. He calls iis://localhost/mimemap the Metabase Path. Which sounds to me like it is some sort of «path» to a «metabase«.
  2. He says that the path to the metabase could be something else; and he gives an example of what it could be like.

Right now i, and the entire planet, are hardcoding the «MetabasePath» as

What should it really be? What should the code be doing to construct a valid MetabasePath?

Note: i’m not getting an access denied error, the error is the same when you have an invalid MetabasePath, e.g. iis://localhost/SoTiredOfThis

2 Answers 2

If you’re working with the IIS config of your local machine i.e. your code and IIS are on the same box then it’s sufficient to specify:

The IIS: portion is also known as a moniker in OLE parlance.

If you open the IIS6 metabase file ( C:\Windows\System32\inetsrv\metabase.xml ) you’ll find a large ‘blob’ of XML. This is in fact a flattened out tree structure.

Paths in the metabase are represented by Location attributes.

The moniker IIS://localhost maps to the Location path /LM which is effectively the tree root.

The moniker IIS://localhost/MimeMap maps to the Location path /LM/MimeMap .

If your code is accessing the metabase on remote machines then instead of specifiying IIS://localhost/[path] , one would specify IIS://[RemoteMachineName]/[path] . This is what Chris Crowes comment means.

IIS://localhost/MimeMap is also the master Mime Type list. All sites inherit this list (the IIS Metabase relies heavily on inherited properties).

If you wanted to override the Mime types for a specific site then you’d modify:

It’s useful to open up the IIS metabase file and have a dig around to understand what’s going on under the bonnet.

Update:

To answer your question about why you can create a DirectoryEntry object where the path is invalid, DirectoryEntry is a general purpose wrapper object used to bind against different types of ADSI providers such as IIS, LDAP and WinNT. It permits creation of DirectoryEntry objects where there may not necessarily be a matching object at the path specified. Some ADSI provider operations may require this capability.

There is a static method on DirectoryEntry called Exists that you can use to test for the existence of objects. For example:

Iis общие сведения о метабазе

Обновлен: Ноябрь 2007

В этом разделе описывается перемещение веб-приложений из IIS версии 6.0 в IIS 7.0. Веб-приложение в IIS 7.0 может быть настроено на использование в классическом или интегрированном режиме. В классическом режиме поддерживается обратная поддержка с ранними версиями IIS путем использования расширения ISAPI для вызова среды выполнения ASP.NET. Этот параметр часто предполагает минимальные изменения (или их отсутствие) в существующих приложениях.

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

Использование интегрированного режима IIS 7.0 может предполагать внесение небольших изменений в файл Web.config. Небольшие изменения могут также потребоваться, если приложение использует любые пользовательские модули с интерфейсом IHttpModule .

Общие сведения относительно конвейера обработки запросов в интегрированном режиме IIS 7.0 см. в разделе Общие сведения о жизненном цикле приложения ASP.NET для служб IIS 7.0 . При использовании IIS 7.0 приложения могут выполняться на сервере как в классическом, так и интегрированном режиме. И классический, и интегрированный режимы поддерживают .NET Framework, версия 2.0 и более поздние версии. .NET Framework версии 1.1 поддерживается только в классическом режиме. Для получения более подробной информации относительно обновления IIS до IIS 7.0 см. документ Обновление приложений ASP.NET до IIS 7.0: различия между встроенным и классическим режимами IIS 7.0 (на английском языке).

Информация в данном разделе может использоваться для перемещения веб-приложений из IIS 5.x в IIS 7.0. Вместе с тем могут потребоваться дополнительные изменения (не описанные в данном документе). Дополнительные сведения см. на странице Обновление ASP.NET 1.1 IIS7 в Windows Server 2003, Windows XP и Windows 2000.

В этом разделе содержатся следующие подразделы:

При переводе веб-приложения ASP.NET в интегрированный режим IIS 7.0 необходимо обновить файл Web.config. IIS 7.0 предполагает изменения, необходимые для возможности администрирования файлов Web.config, и изменения в типах параметров, хранящихся в файлах Web.config. Новые параметры сохраняются в разделе конфигурации system.webServer .

В IIS 6.0 оснастка ASP.NET MMC предоставляет функции администрирования IIS, позволяющие настраивать ASP.NET. Дополнительные сведения см. в разделе Пошаговое руководство. Настройка приложений ASP.NET в IIS 6.0 с помощью консоли управления (MMC) .

В IIS 7.0 администрирование приложений ASP.NET более интегрировано с администрированием IIS (без отдельной оснастки). Вместо этого настройка IIS и ASP.NET выполняется при помощи IIS Manager. Так как данные конфигурации IIS 7.0 сохраняются в системе конфигураций .NET Framework, файл Web.config приложения, которое выполняется в IIS 7.0, содержит параметры веб-сервера и ASP.NET. Например, в файле Web.config приложения ASP.NET, которое выполняется в IIS 7.0, можно указать файл по умолчанию, в который будет осуществляться переход, если обозреватель не запрашивает определенный файл. (В IIS 6.0 и более ранних версиях это обеспечивалось при помощи параметра в метабазе IIS.)

Редактирование файлов Web.config

Файл Web.config веб-приложения, выполняющегося в IIS 7.0, можно редактировать следующим образом:

Непосредственным редактированием файла Web.config, при помощи Visual Studio или Visual Web Developer, или же при помощи текстового редактора.

При помощи IIS Manager. Дополнительные сведения см. в разделе Диспетчер Internet Information Services (IIS).

Использование средства администрирования веб-узла ASP.NET. Дополнительные сведения см. в разделе Средство администрирования веб-узла ASP.NET .

Примечание.

Изменения в средстве администрирования веб-узла не влияют на дочерние элементы конфигурации в system.webServer .

Использование средства командной строки служб IIS 7.0 (Appcmd.exe). Данная служебная программа позволяет вводить параметры конфигурации IIS и веб-приложения в командной строке. Дополнительные сведения см. в разделе Программа командной строки IIS 7.0 (IIS 7.0 Command-Line Tool).

Раздел system.webServer

Раздел конфигурации system.webServer в файле Web.config содержит параметры IIS 7.0, применяемые в веб-приложении. Раздел system.WebServer является дочерним элементом конфигурации. Дополнительные сведения см. на веб-странице IIS 7.0: system.webServer Section Group (IIS Settings Schema).

Примеры параметров веб-сервера, доступные для установки в группе настроек конфигурации system.WebServer , включают:

Стандартный документ, возвращаемый веб-сервером клиенту, если запрос не содержит указание на определенный ресурс (элемент defaultDocument ).

Параметр сжатия ответных сообщений (элемент httpCompression ).

Пользовательские заголовки (элемент customHeaders раздела httpProtocol ).

Модули (элемент modules ).

Обработчики (элемент handlers ).

Некоторые параметры применимы только в интегрированном режиме IIS 7.0 и неприменимы в классическом режиме. Например, если приложение выполняется в классическом режиме, все модули с управляемым кодом и обработчиками, указанными в разделе system.WebServer файла Web.config, будут проигнорированы. Вместо этого модули с управляемым кодом и обработчики должны быть описаны в ранних версиях IIS путем использования элементов httpModules и httpHandlers в разделе system.web.

Примеры использования раздела конфигурации system.webServer см. Практическое руководство. Настройка раздела для служб IIS 7.0 .

В общем случае перевод веб-приложений IIS 6.0 в классический режим IIS 7.0 предполагает перемещение в пул приложений, которые выполняются в классическом режиме. Например, при установке IIS 7.0 и веб-сервер по умолчанию сконфигурирован на работу в интегрированном режиме. Сервер также сконфигурирован на работу с стандартным пулом приложений DefaultAppPool . Чтобы запустить веб-приложение в классическом режиме, используйте приложение Classic.NETAppPool или создайте новый пул приложений, настроенный для работы в классическом режиме. Для получения более подробной информации относительно создания пула приложений см. раздел Создание пула приложений.

Все пользовательские модули, использующие интерфейс IHttpModule в приложениях в классическом режиме, уведомляются только о тех запросах конвейера, которые обрабатываются в среде выполнения ASP.NET. Например, о запросах страниц .aspx. Жизненный цикл приложения в классическом режиме является идентичным жизненному циклу ASP.NET в IIS 6.0. Дополнительные сведения см. в разделе Общие сведения о жизненном цикле приложения ASP.NET для IIS 5.0 и 6.0 .

Если приложение, которое выполняется в классическом режиме, содержит обработчик, требующий наличия карты сценариев для обработки пользовательского расширения в IIS, необходимо зарегистрировать обработчик как в группе httpHandler , так и в группе handler . Нужно сопоставить пользовательское расширение имени файла ASP.NET ISAPI (Aspnet_isapi.dll) указанием атрибутов modules и scriptProcessor в элементе handler . Эти атрибуты указывают, что модуль, описывающий обработчик, является расширением ISAPI, и указывают путь к расширению. Таким образом, в IIS 7.0 в классическом режиме обеспечивается обратная совместимость с более ранними версиями IIS. Вместе с тем при выполнении приложения в интегрированном режиме необходимо удалить атрибуты modules и scriptProcessor . Дополнительные сведения см. в разделе Практическое руководство. Настройка расширений для обработчиков HTTP-данных в IIS .

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

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

Зарегистрировать пользовательские модули и обработчики в разделе system.webServer файла Web.config при помощи методов, описанных в разделе Миграция файла Web Config в интегрированный режим далее.

Определите обработчики событий для событий конвейера запросов HttpApplication , таких как BeginRequest и EndRequest , только в методе Init пользовательского модуля.

Убедитесь, что изучены все вопросы, описанные в разделе «Различия между интегрированным режимом и классическим режимом» документа Обновление приложений ASP.NET до IIS 7.0: различия между встроенным и классическим режимами IIS 7.0 (на английском языке).

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

При переводе приложения из классического в интегрированный режим можно оставить регистрацию пользовательских модулей и обработчиков в классическом режиме или удалить ее. Если регистрации httpModules и httpHandlers в классическом режиме не будут удалены, необходимо установить validation атрибутов элемента validateIntegratedModeConfiguration , чтобы избежать ошибок false . Элемент validation является дочерним для элемента system.webServer . Дополнительные сведения см. в подразделе «Отключение сообщения о миграции» (Disabling the migration error message) раздела Интеграция ASP.NET и служб IIS 7.0 (ASP.NET Integration with IIS 7.0).

Миграция файла Web.config в интегрированный режим

Если модуль или обработчик описаны на уровне приложений, модуль или обработчик не вызываются автоматически. Это относится к модулям и обработчикам, описанным в папке Bin folder или как исходный код в папке App_Code, и не описанным в разделе system.webServer файла Web.config. Чтобы обеспечить включение модуля или обработчика в конвейер обработки запросов в интегрированном режиме, необходимо зарегистрировать модуль (обработчик) одним из методом:

Непосредственно отредактировать файл Web.config, добавив элемент modules или handlers в элемент system.webServer . Следует учесть различия в имени элемента в классическом режиме — modules сравнивается с httpModules и с httpHandlers.

IIS Manager используется для изменения конфигурации модуля или обработчика. Более подробную информацию см. в разделах Конфигурация сопоставлений обработчиков в IIS 7.0 и Конфигурация модулей в IIS 7.0 (на английском языке).

Используйте программу командной строки IIS 7.0 (Appcmd.exe). Более подробную информацию см. в разделе Конфигурация параметров веб-узлов, приложений, виртуальных каталогов или URL-адресов при помощи Appcmd.exe(на английском языке).

Классы и свойства в интегрированном режиме

При работе с приложением в интегрированном режиме IIS 7.0 в версии.NET Framework 3.0 или более поздней можно использовать следующие классы и члены, недоступные в классическом режиме:

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

Свойство Headers объекта HttpResponse , предоставляющее доступ к заголовкам ответов.

Свойства IsPostNotification и CurrentNotification объекта HttpContext , которые используются при предоставлении обработчиков событий HttpApplication .

Свойства Headers и ServerVariables объекта HttpRequest , доступные для изменения.

Оптимизация ASP.NET — практические советы по работе с IIS

В данной публикации речь пойдёт о настройке важных параметров пула ASP.NET-приложений при вызове удалённых веб-сервисов и активной работе с сетью на стороне сервера через стандартные классы .NET.

Введение

Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.

Предыстория

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.

Веб-администаторы проверили всё, что можно, и никак не могли понять, в чём дело. Ведь несмотря на то, что по всем основным параметрам системы на физическом уровне с производительностью было всё хорошо, возникали сбои с доступностью сервисов, а в пуле собиралась огромная очередь запросов. В организации используется NLB-кластер на 4 узла (Windows Server 2008 R2 + IIS 7.5 + .NET 4.5), есть запас по загрузке ЦП и памяти, сетевые каналы большие, количество используемых портов достаточное. Все проверки указывали на то, что проблемы кроются в недрах IIS и настройке пула ASP.NET. Живой пример, когда администраторам не помешала бы помощь опытных веб-разработчиков…

1. Параметры конфигурации IIS

Начиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.

Схема конфигурационных файлов для IIS 7.x и выше выглядит так:

Рис. 1. Схема конфигурационных файлов

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

Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.

Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.

ApplicationHost.config — корневой файл конфигурации IIS, включает в себя описание всех сайтов, приложений, виртуальных каталогов и пулов приложений, а также глобальные установки по умолчанию для параметров веб-сервера. Он находится в следующих папках в зависимости от версии ОС:

  • для 32-битной — %WINDIR%\System32\inetsrv\config\
  • для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\

Каждый локальный файл web.config применяет параметры конфигурации для каталога, в котором он расположен, а также для всех дочерних каталогов. Настройки вложенных каталогов могут быть переопределены собственными “конфигами”.

Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки “HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.

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

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

1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.

Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).

Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

Рис. 2. Установка параметра appConcurrentRequestLimit

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

2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.

Данный параметр можно настроить несколькими способами:

  • глобально для .NET на уровне сервера через machine.config, секция processModel/requestQueueLimit;
  • на уровне IIS через ApplicationHost.config: system.web/httpRuntime -> appRequestQueueLimit;
  • задать значение параметра queueLength для конкретного пула.

В качестве примера изменим данный параметр для пула «DefaultAppPool» через командную строку:

Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.

Рис. 3. Установка параметра queueLength

В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

Рис. 4. Меню Worker Processes в диспетчере IIS

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

Рис. 5. Просмотр работающих пулов через Worker Processes

При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:

Рис. 6. Список текущих запросов в пуле

Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.

2. Настройка ASP.NET

ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто “подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).

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

На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:

Рис. 7. Процесс обработки запросов в ASP.NET

Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно «true» для секции в файле machine.config, а другие ключевые параметры не заданы вообще.

Хорошенько “покопавшись” в MSDN и файле machine.config.comments, я нашёл описание базовой конфигурации пула. Есть 7 основных параметров, влиящих на работу ASP.NET с сервисами и сетью:

  • maxConnection
  • maxWorkerThreads / minWorkerThreads
  • maxIoThreads / minIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads

Параметр maxconnection определяет максимальное количество одновременных запросов с одного IP-адреса. При включенной по умолчанию автоконфигурации пула этот параметр определяется по формуле:
maxConnection = 12 * cpuNum, где cpuNum — это количество ядер процессора

Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).

Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:

Более гибко настраивать maxconnection лучше через конфигурационные файлы на уровне домена приложения (web.config) или веб-сервера (applicationHost.config). Секция содержит параметры, которые определяют, как .NET Framework подключается к сети.

Важно: Схема для адреса параметра maxconnection должна быть такой:

Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.

ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и “подвисать”.

Аттрибуты, заданные в секции :
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.

4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.

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

Аттрибуты, заданные в секции :
1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.

2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.

Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.

ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:
(maxWorkerThreads * число ЦП) — minFreeThreads

Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.

3. Рекомендации по оптимизации базовой конфигурации

Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:

Рис. 8. Окно загрузки процессоров в TaskManager

Также можно попробовать воспользоваться следующими командами в командной строке:

или
Например, на сервере с 4-мя процессорами и свойством autoConfigtrue» ASP.NET будет иметь следующие параметры по умолчанию:
maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.

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

  1. maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
  2. maxIoThreads = 100
  3. maxConnection = 12 * N
  4. minFreeThreads = 88 * N
  5. minLocalRequestFreeThreads = 76 * N, где N — количество процессоров.

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

Изменения в секцию разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinitionMachineOnly» при добавлении секции processModel.

Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinitionEverywhere«.

Важно: после внесения изменений требуется обновить Application pools.

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

Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:

  • ASP.NET Applications\Requests/Sec
  • Web Service\ISAPI Extension Requests/sec
  • ASP.NET\Requests Current
  • ASP.NET\Requests Queued
  • ASP.NET\ Requests Rejected
  • ASP.NET Applications\Requests Executing
  • ASP.NET Applications\Requests Timed Out
  • ASP.NET\ Request Execution Time

Для более глубокого анализа процесса w3wp.exe, обслуживающего пул приложений IIS, можно попробовать отладчик WinDbg из Windows Software Development Kit.

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

Дополнительно

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

Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».

Заключение

Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.

Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются “зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, “предупрежден — значит вооружен”.

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

Продукты Vault

Знания

Изучите основы и оттачивайте навыки для повышения эффективности работы в Продукты Vault

«Требуется доступ к метабазе Vista IIS» при установке Vault Server

Support

Проблема

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

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

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

Определение веб-сайта IIS Интернет-адрес по умолчанию.
Требуется доступ к метабазе Vista IIS. Пожалуйста, нажмите, чтобы получить информацию о включении этой функции.

Проверка существования виртуального каталога «AutodeskDM»
Требуется доступ к метабазе Vista IIS. Пожалуйста, нажмите, чтобы получить информацию о включении этой функции.

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

Проверка статуса ASP
Требуется доступ к метабазе Vista IIS. Пожалуйста, нажмите, чтобы получить информацию о включении этой функции.

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

Причины

Решение

Убедитесь, что в окнах информационных служб Интернета установлена функция «Совместимость метабазы IIS и IIS 6».

Опция 1
В панели управления> «Включение или отключение компонентов Windows» убедитесь, что установлены все следующие функции. (Порядок появления будет отличаться в разных операционных системах.)

IIS: Как получить Metabase путь?

Я пытаюсь получить список типов mime, известных серверу IIS (который вы можете видеть, и мне ответил 2 года назад). Вложенный ответ:

Вы получаете идею. Все согласны с тем, что вы используете магический путь iis://localhost/mimemap. И это отлично работает, за исключением тех случаев, когда этого не происходит.

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

Здесь есть два ключа:

  • Он называет iis://localhost/mimemap путь метабазы ​​. Что звучит для меня так, как будто это своего рода «путь» к «метабазе».
  • Он говорит, что путь к метабазе может быть чем-то другим; и он дает пример того, как это может быть.

Прямо сейчас я и вся планета жестко кодируют » MetabasePath» как

Что должно быть на самом деле? Что должен делать код для создания действительного MetabasePath?

Примечание. Я не получаю ошибку отказа в доступе, ошибка такая же, когда у вас есть неверный MetabasePath, например. iis://localhost/SoTiredOfThis

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

Часть IIS: также известна как прозвище на языке OLE.

Если вы откроете файл метабазы ​​IIS6 ( C:\Windows\System32\inetsrv\metabase.xml ), вы увидите большой «blob» XML. Это фактически сглаженная древовидная структура.

Пути в метабазе представлены атрибутами Location .

Прозвище IIS://localhost отображает путь Location /LM , который фактически является корнем дерева.

Прозвище IIS://Localhost/mimemap отображается на путь Location /LM/MimeMap .

Если ваш код обращается к метабазе на удаленных компьютерах, вместо указания IIS://localhost/[path] следует указать IIS://[RemoteMachineName]/[path] . Это то, что комментирует Крис Кроуз.

IIS://Localhost/mimemap также является основным типом списка Mime. Все сайты наследуют этот список (метабаза IIS в значительной степени зависит от унаследованных свойств).

Если вы хотите переопределить типы Mime для определенного сайта, вы должны изменить:

Полезно открыть файл метабазы ​​IIS и поработать, чтобы понять, что происходит под капотом.

Update:

Чтобы ответить на вопрос о том, почему вы можете создать объект DirectoryEntry , где путь недействителен, DirectoryEntry — это объект оболочки общего назначения, используемый для привязки к различным типам поставщиков ADSI, таких как IIS, LDAP и WinNT. Это позволяет создавать объекты DirectoryEntry , где не обязательно должен быть соответствующий объект по указанному пути. Некоторым операциям провайдера ADSI может потребоваться эта возможность.

Существует статический метод на DirectoryEntry , называемый Exists , который вы можете использовать для проверки существования объектов. Например:

Для системного администратора

Начало работы с IIS 7.0 в Windows Server 2008

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

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

Новая архитектура

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

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

Новая модель IIS 7.0 позволяет выбрать устанавливаемые на сервере функции, называемыми модулями. Эти модули встраиваются непосредственно во встроенный конвейер обработки запросов. Эта новая модульная конструкция имеет несколько преимуществ, включая уменьшение количества возможных направлений атак и размера веб-сервера.
В данный момент в состав IIS входит 40 модулей по умолчанию — например, обычная, анонимная проверка подлинности и проверка подлинности Windows® теперь выделены в отдельные модули, которые могут добавляться к конвейеру обработки запросов независимо. Для упрощения классификации модули сгруппированы в восемь подкатегорий (см. рис. 1).

Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей

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

Встроенный конвейер обработки запросов

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

Рис. 2 Интегрированный конвейер и модули IIS 7.0

Каждый веб-узел на сервере имеет встроенный конвейер обработки запросов и может быть запущен в одном из двух режимов – встроенном или классическом. Встроенный режим, режим по умолчанию, позволяет подключать к конвейеру определенные функциональные возможности, обеспечивая настраиваемый контроль над обработкой запроса. Для обеспечения совместимости классический режим воспроизводит функции IIS 6.0/ISAPI с помощью модуля ISAPI в конвейере. Это очень полезно при переносе приложений в IIS 7.0.

Установка по умолчанию

Рассмотрим настройку нового модульного веб-сервера. Если взглянуть на установку IIS 7.0 по умолчанию, можно заметить, что включены только 10 модулей (если включена служба активации процессов Windows). Настройка IIS 7.0 предоставляет базовую функциональность IIS при установке роли веб-сервера, в частности, только модули, необходимые для предоставления статического содержимого, например, обычного кода HTML или классических страниц ASP. Последующая установка дополнительных компонентов на сервере определяется только вами. Ниже приведены функциональные возможности, включенные в установку по умолчанию:

* Основные функции HTTP, включая статическое содержимое, документ по умолчанию, обзор каталога и ошибки HTTP
* Функции работоспособности и диагностики, такие как ведение журнала HTTP и монитор запросов
* Функции безопасности, такие как фильтрация запросов
* Функции повышения производительности, такие как сжатие статического содержимого
* Средства управления, в том числе консоль управления IIS
* Служба активации процессов Windows

Как видите, это сервер с минимально необходимым количеством компонентов, в состав включающий ASP.NET и другие новые функции IIS 7.0, такие как функции диагностики и устранения неисправностей. Добавление на сервер дополнительных функциональных возможностей, таких как возможность передачи динамического содержимого, например, ASP.NET и FastCGI (PHP), осуществляется очень просто. Выберите необходимый для установки набор модулей в разделе «Add Role Services» (Добавление служб роли) роли веб-сервера в диспетчере Windows Server® 2008 Server Manager.

Новое хранилище настроек

Другим ключевым изменением в IIS 7.0, упрощающим вашу работу, является новое хранилище настроек. Метабаза, теперь являющаяся дополнительным устанавливаемым компонентов для обеспечения обратной совместимости, заменена системой настроек на основе XML. Я уже слышу, как вы говорите: «Но метабаза была в формате XML!» Да, была. Но она была громоздкой и не простой для чтения (по крайней мере, человеческого). Она заменена более гибкой системой XML. Подобно ASP.NET, IIS 7.0 использует файлы .config — простые, ясные, переносимые и простые для чтения файлы.
Переход на этот формат означает, что теперь система настроек независима от компьютера, в отличие от метабазы, которая была прикреплена к отдельному компьютеру. Как следствие, теперь система настроек может быть просто перенесена на другие серверы с помощью обычного перетаскивания или команды xcopy.

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

Включение настройки общего пользования осуществляется очень просто. На узле сервера диспетчера служб IIS выберите пункт «Shared Configuration» (Настройка общего пользования), который находится в разделе «Управление» на панели задач. Просто установите флажок «Enable shared configuration» (Включить настройки общего пользования), укажите физический путь к файлу настройки для совместного использования (обычно это общая папка UNC), введите учетные данные, необходимые для доступа к физическому пути, и нажмите кнопку «Применить». После нахождения файла .config появится запрос на ввод пароля шифрования. После завершения процесса перезапустите диспетчер служб IIS, чтобы он выбрал новый файл .config.

Поскольку структура новой системы настроек отличается от той, к которой вы привыкли, рассмотрим ее основы. Как показано на рис. 3, настройка IIS 7.0 разделена на две категории – параметры уровня сервера и параметры узла. Все параметры уровня сервера хранятся в файле applicationhost.config, который находится в папке %systemroot%\windows\system32\inetsrv\config. К ним относятся параметры всех установленных модулей, узлов на сервере и т.д. Параметры узла хранятся в отдельных файлах web.config.

Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере

Если вы использовали ASP.NET, вы, наверное, знакомы с файлами web.config. Службы IIS 7.0 используют файлы web.config для хранения параметров отдельных веб-узлов, таких как документ узла по умолчанию и параметры приложений, а также параметры ASP.NET. Это означает, что для каждого узла на сервере существует файл web.config.
Файл web.config узла находится в физическом пути к узлу, например, %systemroot%\inetpub\wwwroot. Такая модель предоставляет такие же преимущества переносимости, которые были описаны ранее, но на уровне узла. Например, можно просто разработать узел на тестовом сервере, а затем перенести файл web.config и файлы приложения на рабочий сервер с помощью перетаскивания или функции xcopy.

При переносе или совместном использовании файлов .config следите за сведениями, зависящими от компьютера, такими как IP-адрес и буквы дисков. Службы IIS 7.0 предоставляют решение для возможных ошибок в подобных параметрах, поддерживая переменные среды операционной системы (например, %systemroot%). Кроме того, убедитесь, что на тестовых и рабочих серверах установлен одинаковый набор модулей. Это поможет избежать появления непредвиденных ошибок приложений. Ошибки также могут возникать, если в файле web.config содержится ссылка на неустановленный модуль или в случае конфликта стандартного модуля с пользовательским.

Управление веб-сервером

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

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

В IIS 6.0 пользовательский интерфейс оснастки консоли управления Microsoft® (MMC) имеет два основных знакомых представления, представление в виде дерева и представление в виде вкладок. Для перехода к определенному параметру необходимо щелкнуть его правой кнопкой мыши и выбрать «Properties» (Свойства), после чего появится набор вкладок, не говоря уж о переключателях и флажках.

К счастью, пользовательский интерфейс в IIS 7.0 полностью переработан. Этот пользовательский интерфейс, называемый диспетчером служб IIS, задумывался для реализации подхода, ориентированного на задачи, как показано на рис. 4. Также существует диспетчер Remote Manager для клиентов нижнего уровня, таких как Windows XP и Windows Server 2003. Его можно загрузить с веб-узла IIS.net/downloads.

Рис. 4 Новый пользовательский интерфейс в IIS 7.0

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

В диспетчер служб IIS также интегрированы свойства ASP.NET, избавляя от необходимости использовать дополнительную оснастку MMC. Каждое настраиваемое свойство имеет собственный значок, что упрощает поиск свойств. А поскольку диспетчер служб IIS создавался как приложение Windows Forms, можно легко добавлять значки подключаемых модулей для любых созданных пользовательских модулей или функций.

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

Удаленное управление и делегированное администрирование

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

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

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

Служба удаленного управления в IIS 7.0 фактически представляет собой небольшое веб-приложение, работающее как отдельная служба под учетной записью локальной службы Windows NT® с именем NT Service\WMSVC. Такая модель обеспечивает сохранение возможности удаленного управления, даже если сам сервер IIS не отвечает.

Как и большинство функций IIS 7.0, удаленное управление в целях безопасности не установлено по умолчанию. Для установки функций удаленного управления добавьте службы ролей для роли веб-сервера в диспетчере сервера Windows Server 2008, который находится в разделе «Management Tools» (Средства управления). После установки функции необходимо включить удаленные подключения и запустить службу WMSVC, поскольку по умолчанию она остановлена.
Параметр запуска службы WMSVC по умолчанию – вручную. При необходимости автоматического запуска службы после перезагрузки необходимо изменить значение параметра на автоматический запуск. Это можно сделать, введя следующее в командной строке:

sc config WMSVC start=auto

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

Первый вариант, указывающий на разрешение только учетных записей пользователей Windows, локальных или доменных, является довольно очевидным. По второму варианту проходят как пользователи Windows, так и тип учетной записи, являющийся совершенно новым в IIS 7.0 и не связанным с учетными записями пользователей Windows: пользователи диспетчера IIS. Учетные записи пользователей диспетчера IIS позволяют администраторам создавать учетные записи пользователей, известные только в контексте IIS 7.0 и не имеющие прав доступа к операционной системе. Наконец, службы IIS по умолчанию предоставляют самоподписанный сертификат, чтобы можно было начать работу, но рекомендуется добавить действительный подписанный сертификат SSL. Теперь необходимо просто применить параметры и запустить службу.

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

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

Переход на IIS 7.0

При создании служб IIS 7.0 группа разработчиков стремилась к тому, чтобы переход на них осуществлялся как можно более плавно, позволяя использовать некоторые существующие вложения в средства управления и сценарии для IIS 6.0. Была тщательно продумана обратная совместимость служб IIS 7.0, чтобы они могли работать со сценариями IIS 6.0. На узле совместимости управления IIS 6.0 программы установки можно установить весь набор средств — от совместимости метабазы IIS 6.до самой консоли управления IIS 6.0.

В инфраструктуре совместимости метабазы IIS 6.0 используется компонент с названием ADOMapper. Он позволяет выполнять сценарии метабазы объектов на основе администратора (ABO) и интерфейса ADSI IIS 6.0 в новой системе настроек, ограничивая ее только возможностями IIS 6.0. Поэтому чтение и запись новых свойств IIS 7.0, доступ к новым данным выполнения, чтение и запись свойств ASP.NET или файлов web.config невозможны.

Устранение неполадок и диагностика

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

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

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

Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей

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

Автор: Айзек Ройбал (Isaac Roybal)
Источник: мартовский выпуск Technet Magazine

IIS: Как получить путь метабазы?

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

Вы поняли идею. Все согласны с тем, что вы используете магический путь iis: // localhost / mimemap . И это прекрасно работает, за исключением случаев, когда это не так.

Единственная подсказка, которую я могу найти относительно того, почему это терпит неудачу, от IIS MVP, блог Криса Кроу :

Здесь есть две подсказки:

  1. Он вызывает iis://localhost/mimemap как путь метабазы . Что звучит для меня так, будто это какой-то « путь » к « метабазе ».
  2. Он говорит, что путь к метабазе может быть чем-то другим; и он приводит пример того, что это может быть.

Прямо сейчас я и вся планета жестко кодируем » MetabasePath » как

Что это должно быть на самом деле? Что должен делать код для создания допустимого MetabasePath?

Примечание: я не получаю ошибку об отказе в доступе, ошибка такая же, когда у вас неверный MetabasePath, например, iis://localhost/SoTiredOfThis

2 ответа

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

Часть IIS: также называется прозвищем на языке OLE.

Если вы откроете файл метабазы IIS6 ( C:\Windows\System32\inetsrv\metabase.xml ), вы увидите большой «блоб» XML. Это на самом деле уплощенная древовидная структура.

Пути в метабазе представлены атрибутами Location .

Моникер IIS://localhost отображается на путь Location /LM который фактически является корнем дерева.

Моникер IIS://localhost/MimeMap отображается на путь расположения /LM/MimeMap .

Если ваш код обращается к метабазе на удаленных компьютерах, то вместо указания IIS://localhost/[path] можно указать IIS://[RemoteMachineName]/[path] . Вот что означает комментарий Криса Кроуза.

IIS://localhost/MimeMap также является основным списком Mime Type. Все сайты наследуют этот список (метабаза IIS сильно зависит от унаследованных свойств).

Если вы хотите переопределить типы Mime для определенного сайта, вы должны изменить:

Полезно открыть файл метабазы IIS и покопаться, чтобы понять, что происходит под капотом.

Обновить:

Чтобы ответить на ваш вопрос о том, почему вы можете создать объект DirectoryEntry путь которого недопустим, DirectoryEntry — это объект-оболочка общего назначения, используемый для привязки к различным типам поставщиков ADSI, таким как IIS, LDAP и WinNT. Это позволяет создавать объекты DirectoryEntry где не обязательно может быть соответствующий объект по указанному пути. Некоторые операции поставщика ADSI могут требовать этой возможности.

В DirectoryEntry Exists статический метод Exists , который можно использовать для проверки существования объектов. Например:

Оптимизация ASP.NET — практические советы по работе с IIS

В данной публикации речь пойдёт о настройке важных параметров пула ASP.NET-приложений при вызове удалённых веб-сервисов и активной работе с сетью на стороне сервера через стандартные классы .NET.

Введение

Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.

Предыстория

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.

Веб-администаторы проверили всё, что можно, и никак не могли понять, в чём дело. Ведь несмотря на то, что по всем основным параметрам системы на физическом уровне с производительностью было всё хорошо, возникали сбои с доступностью сервисов, а в пуле собиралась огромная очередь запросов. В организации используется NLB-кластер на 4 узла (Windows Server 2008 R2 + IIS 7.5 + .NET 4.5), есть запас по загрузке ЦП и памяти, сетевые каналы большие, количество используемых портов достаточное. Все проверки указывали на то, что проблемы кроются в недрах IIS и настройке пула ASP.NET. Живой пример, когда администраторам не помешала бы помощь опытных веб-разработчиков…

1. Параметры конфигурации IIS

Начиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.

Схема конфигурационных файлов для IIS 7.x и выше выглядит так:

Рис. 1. Схема конфигурационных файлов

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

Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.

Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.

ApplicationHost.config — корневой файл конфигурации IIS, включает в себя описание всех сайтов, приложений, виртуальных каталогов и пулов приложений, а также глобальные установки по умолчанию для параметров веб-сервера. Он находится в следующих папках в зависимости от версии ОС:

  • для 32-битной — %WINDIR%\System32\inetsrv\config\
  • для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\

Каждый локальный файл web.config применяет параметры конфигурации для каталога, в котором он расположен, а также для всех дочерних каталогов. Настройки вложенных каталогов могут быть переопределены собственными “конфигами”.

Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки “HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.

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

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

1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.

Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).

Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

Рис. 2. Установка параметра appConcurrentRequestLimit

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

2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.

Данный параметр можно настроить несколькими способами:

  • глобально для .NET на уровне сервера через machine.config, секция processModel/requestQueueLimit;
  • на уровне IIS через ApplicationHost.config: system.web/httpRuntime -> appRequestQueueLimit;
  • задать значение параметра queueLength для конкретного пула.

В качестве примера изменим данный параметр для пула «DefaultAppPool» через командную строку:

Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.

Рис. 3. Установка параметра queueLength

В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

Рис. 4. Меню Worker Processes в диспетчере IIS

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

Рис. 5. Просмотр работающих пулов через Worker Processes

При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:

Рис. 6. Список текущих запросов в пуле

Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.

2. Настройка ASP.NET

ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто “подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).

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

На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:

Рис. 7. Процесс обработки запросов в ASP.NET

Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно «true» для секции в файле machine.config, а другие ключевые параметры не заданы вообще.

Хорошенько “покопавшись” в MSDN и файле machine.config.comments, я нашёл описание базовой конфигурации пула. Есть 7 основных параметров, влиящих на работу ASP.NET с сервисами и сетью:

  • maxConnection
  • maxWorkerThreads / minWorkerThreads
  • maxIoThreads / minIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads

Параметр maxconnection определяет максимальное количество одновременных запросов с одного IP-адреса. При включенной по умолчанию автоконфигурации пула этот параметр определяется по формуле:
maxConnection = 12 * cpuNum, где cpuNum — это количество ядер процессора

Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).

Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:

Более гибко настраивать maxconnection лучше через конфигурационные файлы на уровне домена приложения (web.config) или веб-сервера (applicationHost.config). Секция содержит параметры, которые определяют, как .NET Framework подключается к сети.

Важно: Схема для адреса параметра maxconnection должна быть такой:

Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.

ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и “подвисать”.

Аттрибуты, заданные в секции :
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.

4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.

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

Аттрибуты, заданные в секции :
1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.

2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.

Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.

ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:
(maxWorkerThreads * число ЦП) — minFreeThreads

Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.

3. Рекомендации по оптимизации базовой конфигурации

Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:

Рис. 8. Окно загрузки процессоров в TaskManager

Также можно попробовать воспользоваться следующими командами в командной строке:

или
Например, на сервере с 4-мя процессорами и свойством autoConfigtrue» ASP.NET будет иметь следующие параметры по умолчанию:
maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.

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

  1. maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
  2. maxIoThreads = 100
  3. maxConnection = 12 * N
  4. minFreeThreads = 88 * N
  5. minLocalRequestFreeThreads = 76 * N, где N — количество процессоров.

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

Изменения в секцию разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinitionMachineOnly» при добавлении секции processModel.

Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinitionEverywhere«.

Важно: после внесения изменений требуется обновить Application pools.

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

Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:

  • ASP.NET Applications\Requests/Sec
  • Web Service\ISAPI Extension Requests/sec
  • ASP.NET\Requests Current
  • ASP.NET\Requests Queued
  • ASP.NET\ Requests Rejected
  • ASP.NET Applications\Requests Executing
  • ASP.NET Applications\Requests Timed Out
  • ASP.NET\ Request Execution Time

Для более глубокого анализа процесса w3wp.exe, обслуживающего пул приложений IIS, можно попробовать отладчик WinDbg из Windows Software Development Kit.

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

Дополнительно

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

Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».

Заключение

Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.

Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются “зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, “предупрежден — значит вооружен”.

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

How to install the IIS 6 Metabase Compatibility components on IIS

The ActiveXperts Network Monitor Web Configurator requires that the Windows Server 2012/2008 based or Windows 10/8/7/Vista-based computer where you are configuring a Virtual Directory has the IIS 6 Metabase Compatibility components installed.

To install the IIS 6.0 Management Compatibility Components by using the Windows Server 2012/2008 Server Manager

  • Click Start, click Administrative Tools and then Server Manager.
  • In the left navigation pane, expand Roles, and then right-click Web Server (IIS) and select Add Role Services.
  • On the Select Role Services pane, scroll down to IIS 6 Management Compatibility.
  • Select the check boxes for IIS 6 Metabase Compatibility and IIS 6 Management Console.
  • Click Next from the Select Role Services pane, and then click Install at the Confirm Installations Selections pane.
  • Click Close to leave the Add Role Services wizard.

To install the IIS 6.0 Management Compatibility Components by using the Windows 8/7/Vista Control Panel

  • Click Start, click Control Panel, click Programs and Features, and then click Turn Windows features on or off.
  • Open Internet Information Services.
  • Open Web Management Tools.
  • Open IIS 6.0 Management Compatibility.
  • Select the check boxes for IIS 6 Metabase and IIS 6 configuration compatibility and IIS 6 Management Console.
  • Click OK.
Илон Маск рекомендует:  option в HTML
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Примечание.