Iis отслеживание использования процессора


Где у IIS есть монитор подключений?

18.03.2009, 14:21

Где скачать IIS?
Подскажите пожалуйста, где скачать ISS (Internet Information Server)? И как задать ему рабочий.

Где скачать IIS?
Где скачать IIS версии 6.0 или выше?

Где взять IIS для Windows?
Здравствуйте! Дайте пожалуйста ссылку на скачивание IIS для Windows. Желательно версии 6.0.

Где хранится история подключений по ssh?
CentOS 6.4. Простой админский вопрос. Нужно узнать IP. Время, в которое был выход по ssh, я.

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

18.03.2009, 15:25 2

> Есть ли какой-нибудь ‘монитор’, чтобы видеть все подключения к серверу в данный момент?
Control Panel -> Administrative Tools -> Perfomance
И добавляешь нужные счетчики для нужного компа из раздела Web Services

> Как настроить Permisson для IIS?
Какие именно рermissons имеются в виду
Настройки доступп IIS меняются через Internet Services Manager в панели управления. Также IIS ‘подчиняется’ правам NTFS выданным на файлы/каталоги веб-сервера.
Все это подробно описывается в справке по IIS

Iis отслеживание использования процессора

Программа Fiddler — это прокси, позволяющий просматривать все клиентские HTTP запросы и отслеживать трафик между локальным ПК и удаленным сервером/сервисом.

Она отлично работает, например, при отладке клиентской части сайта, позволяет просматривать внешние запросы, параметры и данные форм и куки (cookies).

Но при работе с веб-сервисами (web services), когда, например, нужно отследить по какому URL адресу сервис осуществил запрос, без дополнительной настройки программы Fiddler данного действия не увидеть. Это возможно, если сайт работает через инструмент Cassini, но в случае с IIS — Fiddler не покажет необходимую информацию о трафике сервиса.

Причина кроется в учетных записях, от имени которых работают IIS и Fiddler. Они оба запускаются под администратором. А вот приложения (сайты, сервисы) под управлением IIS работают уже из-под учетной записи «Network Service». Если бы можно было запустить Fiddler под Network Service, проблема была бы решена, но к сожалению, это невозможно.

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

Сделаем следующие шаги:

1) Добавим пользователя, обладающего правами администратора, в группу IIS_IUSRS (для IIS 7 и младше) или в группу IIS_WPG (для IIS 6 и старше) (группа обладает правами сетевой службы).

Для этого переходим:

Computer Management -> Local Users and Groups -> Groups -> IIS_IUSRS/IIS_WPG и добавляем в группу администратора.

2) Теперь необходимо настроить пул веб-приложения (Application Pool) для его запуска под учетной записью администратора.

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

Итак, заходим в IIS, в списке пулов (Application Pools) выбираем нужный пул и переходим в его расширенные настройки (Advanced Settings):

В настройках пула в параметре Identity выбираем Custom account и по нажатию на Set — прописываем учетные данные администратора (логин и два раза пароль):


При необходимости связываем пул приложения (Application Pool) с веб-приложением. Для этого переходим в расширенные настройки нужного сайта/приложения и указываем пул:

Теперь можно запускать Fiddler, стартовать сайт/сервис и программа будет отслеживать все его запросы.

Установка CentOS 7 на виртуальную машину Hyper-V второго поколения (Generation 2)

Пул приложений IIS Высокое использование ЦП, несмотря на отсутствие запросов

Недавно я перенес набор серверов Windows Server 2008 R2 /IIS 7.5 на новые серверы под управлением Windows Server 2012 /IIS 8.

Я испытываю некоторое нечетное поведение от IIS. У нас есть 2 одинаковых сервера, на каждом сервере работает 2 веб-сайта, каждый из которых находится в собственном пуле приложений. Код для каждого из веб-сайтов идентичен. (Буквально . то же, что и у dll и всего, только немного другая конфигурация).

Пулы приложений настроены на переработку по расписанию каждые 24 часа, но в течение этого 24-часового периода загрузка процессора рабочим процессом w3wp возрастает с шагом 12,5% (на сервере имеется 8 процессоров, поэтому я не думаю, что это совпадение).

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

Я несколько уверен, что эта проблема не имеет ничего общего с моим кодом, но какая-то плохая конфигурация IIS или изменение в IIS 8, которая плохо работает с конфигурацией оборудования или что-то в этом роде?

Не уверен, что это важно или нет, но это Rackspace Performance Cloud.

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

Кто-нибудь наблюдал это поведение? Я нашел этот вопрос с 2009 года, когда у кого-то возникла проблема с IIS 6:

Как отслеживать производительность сервера IIS

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

У меня есть Perfmon и работает, загрузка процессора обычно ниже 20% (один proc. не спрашивайте). База данных гудит. И я дергаю себя за волосы. из.

Итак, какие метрики / инструменты вы считаете полезными при оценке производительности IIS?

3 ответов

посмотрите, что сделали лучшие сайты:
критерии
ТОП 100

мой опыт говорит:
— Включить сжатие (GZIP/Deflate) в IIS для статических данных. Простой в реализации и с отличными результатами.
— если процессор не ваша проблема, попробуйте включить сжатие для динамических данных.

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

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

Работа конвейера веб-сервера 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

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

Обработка запросов в 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.

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

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

IIS monitoring tool

I have a need for a tool that would monitor and more importantly log requests on IIS. This tool would have to report basic info about requests such as date/time of request, time spent for request, kbytes transferred. etc

What do you people use for such monitoring?

5 Answers 5

You should extend and add all of the IIS properties you want to log.

To do this, do the following:

  1. Go into IIS
  2. Select properties on your website.
  3. Under the website tab, choose properties in the logging section.
  4. Select the Extended Properties tab.
  5. Select extended properties
  6. Select all of the items you want to log.

CPU Throttling в IIS 8

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

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

Настройки CPU Throttling входят в конфигурацию пула приложений и настраиваются следующим образом.

Если надо включить ограничение для одного конкретного пула приложений, то выбираем его из списка и переходим в раздел «Advanced Settings». Если же надо задать дефолтные ограничения для всех пулов, то идем в раздел «Set Application Pool Defaults».

В настройках переходим в раздел CPU, где нас интересуют следующие настройки:

• Limit — максимальный процент процессорного времени, который может использовать пул приложений. При превышении этого значения производится действие, указанное в поле Limit Action. В IIS 8 процент задается в тысячных долях процента (1\1000 of %), т.е. чтобы задать ограничение в 30% в поле Limit надо указать значение 30000. В IIS 8.5 значение задается по человечески, в процентах;
• Limit Action — действие, которые должны произойти с пулом при достижении заданного лимита нагрузки CPU;
• Limit Interval — период проверки и сброса результата мониторинга нагрузки. Этот параметр не используется при тротлинге и предназначен в основном для обеспечения совместимости с предыдущими версиями IIS.

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

После установки лимита в поле Limit Action надо выбрать действие, которые должны произойти с пулом при достижении заданного лимита:


• NoAction — генерируется событие, производится запись в системный журнал. Никаких действий производиться не будет;
• KillW3wp — рабочий процесс для пула останавливается на время, указанное в поле Limit Interval. Событие записывается в системный журнал;
• Throttle — жестко ограничивает доступную для пула процессорную мощность значением, указанным в поле Limit. Limit Interval не используется и запись в журнал не производится;
• ThrottleUnderLimit — ограничение работает в том случае, если сервер сильно нагружен. При небольшой нагрузке на сервер пул может превысить ограничение. Также как и в предыдущем случае Limit Interval не используется и запись в журнал не производится.

Также настройки можно произвести с помощью консольной утилиты appcmd. Так например для включения для DefaultAppPool тротлинга при 30% нагрузке надо открыть командную строку и выполнить команду:

%systemroot%\system32\inetsrv\appcmd set apppool DefaultAppPool /cpu.limit:30000 /cpu.action:Throttle

А настроить эти значения как дефолтные для всех пулов можно командой:

%systemroot%\system32\inetsrv\appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.cpu.limit:30000 /cpu.action:Throttle /commit:apphost

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

Настройка IIS

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

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

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

В IIS имеется два механизма кеширования: кеш в пространстве пользователя и кеш в пространстве ядра.

Кеширование в пространстве пользователя

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

Чтобы настроить кеширование, откройте приложение IIS Manager, выберите свое веб-приложение, откройте настройку Output Caching (Кеширование вывода), щелкните на ссылке Add (Добавить) в панели Actions (Действия), чтобы добавить новое правило кеширования, или выберите существующее правило для редактирования.

Чтобы создать новое правило кеширования в пространстве пользователя, добавьте новое правило, введите расширение имен файлов, которые требуется кешировать, и отметьте флажок User-mode caching (Кеширование в режиме пользователя) в диалоге Add Cache Rule (Добавить правило кеширования), как показано на рисунке ниже:

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

После добавления правила кеширования, настройки сохраняются в файле web.config приложения, в разделе system.webServer caching. Например, для правила кеширования страниц .aspx на срок до 30 минут, с учетом HTTP-заголовка Accept-Language, будет сгенерирован следующий код в конфигурационном файле:

Кеширование в пространстве ядра

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

Настройка правил кеширования в пространстве ядра выполняется почти так же, как кеширование в пространстве пользователя. В диалоге настройки правила установите флажок Kernel-mode caching (Кеширование в режиме ядра) и выберите желаемый способ кеширования.

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

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

Настройка пула приложения

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

Илон Маск рекомендует:  Node, Express и libsass проект с нуля


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

Перезапуск

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

Для проверки количества и частоты перезапусков пула приложения можно использовать счетчик производительности ASP.NET\Worker Process Restarts. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.

Тайм-аут простоя

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

Привязка процессов к ядрам процессора

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

Веб-сад

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

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

Другим примером, когда может пригодиться наличие нескольких процессов, выполняющих одно и то же веб-приложение — использование 64-разрядного сервера IIS, выполняющего 32-разрядное веб-приложение. 64-разрядные серверы обычно имеют большой объем памяти, а 32-разрядное приложение может использовать не более 2 Гбайт, что часто приводит к увеличению частоты сборки мусора и, вероятно, к перезапускам пула приложения. Поддерживая два или три рабочих процесса для 32-разрядного веб-приложения, можно добиться более полного использования памяти сервера, уменьшить частоту сборки мусора и перезапусков пула приложения.

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

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

Iis отслеживание использования процессора

Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1

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

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

Итак, приступаем. Ускоряем сайт на ASP.NET — экономим деньги предприятия и нервы администратора.

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

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

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

Общее описание конфигурации .NETНачиная с 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%System32inetsrvconfig
  • для 64-битной — %WINDIR%SysWOW64inetsrvconfig

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

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

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

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

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

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

cd %windir%system32inetsrv
appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:20000

Выполняем команду, затем открываем в 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» через командную строку:


appcmd.exe set apppool «DefaultAppPool» /queueLength:20000

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

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

На заметку: Просмотр текущих запросов в работающем пуле через “IIS ->Worker Processes”В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

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

Рис. 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 указать следующее:

// maximum number of concurrent connections allowed by a ServicePoint object
System.Net.ServicePointManager.DefaultConnectionLimit = Int16.MaxValue;


Более гибко настраивать 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

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

WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors
илиecho %NUMBER_OF_PROCESSORS%

Например, на сервере с 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 ApplicationsRequests/Sec
  • Web ServiceISAPI Extension Requests/sec
  • ASP.NETRequests Current
  • ASP.NETRequests Queued
  • ASP.NET Requests Rejected
  • ASP.NET ApplicationsRequests Executing
  • ASP.NET ApplicationsRequests 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.

IIS 7 — как отследить использование загадочной сети и процессора?

У меня есть 64-битная версия Server 2008 (R1) под управлением IIS. Пользователи жаловались на крайне медленно загружаемые страницы. Покопавшись, я обнаружил:

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

NewRelic показывает> 10 секунд, потерянных для «сети», даже если весь доступ осуществляется через 100-мегабайтную локальную сеть, а perfmon показывает нулевую длину очереди вывода в сети.

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL