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

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

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

Введение

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

Итак, приступаем. Ускоряем сайт на ASP.NET — экономим деньги предприятия и нервы администратора.Предыстория1. Параметры конфигурации IIS2. Настройка ASP.NET3. Рекомендации по оптимизации базовой конфигурацииДополнительноЗаключениеСсылки

Предыстория

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 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 был значительно упрощен, и он располагается в каталоге:

%systemroot%\Microsoft.NET\Framework\<versionNumber>\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, так и для отдельного сайта (приложения).

cd %windir%\system32\inetsrv appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:20000 Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

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

Для установки данного параметра наиболее часто используется формула: <usersCount * 1.5>, где 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»:

Рис. 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" для секции <processModel> в файле 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). Секция system.net> содержит параметры, которые определяют, как .NET Framework подключается к сети.<system.net> <connectionManagement> <add address="*" maxconnection="5000" /> <add address = "http://www.habrahabr.ru" maxconnection = "9999" /> <add address = "http://65.53.32.230:88" maxconnection = "240" /> </connectionManagement> </system.net> Важно: Схема для адреса параметра maxconnection должна быть такой:http(s)://<IP-адрес или Имя сервера>:<Порт> Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.

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

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

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

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

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

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

Аттрибуты, заданные в секции <httpRuntime>: 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-мя процессорами и свойством autoConfig="true" ASP.NET будет иметь следующие параметры по умолчанию: maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.

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

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

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

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

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Machine.config:

<section name="processModel" type="System.Web.Configuration.ProcessModelSection, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineOnly" allowLocation="false" /> Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition="Everywhere".Приведу настройки конфигурации с нашего веб-сервера<system.web> <processModel autoConfig="False" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="8" /> <httpRuntime minFreeThreads="640" minLocalRequestFreeThreads="96"> </system.web> <system.net> <connectionManagement> <add address = "http://Адрес_сервера_1" maxconnection = "5000" /> <add address = "http://Адрес_сервера_2" maxconnection = "5000" /> </connectionManagement> </system.net>Важно: после внесения изменений требуется обновить 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.

Ссылки

habr.com

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

Введение

Предыстория

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

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

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

%systemroot%Microsoft.NETFramework<versionNumber>CONFIG

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

для 32-битной — %WINDIR%System32inetsrvconfig
для 64-битной — %WINDIR%SysWOW64inetsrvconfig

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

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

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

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

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

глобально для .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»:

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

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

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

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

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

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

maxConnection
maxWorkerThreads / minWorkerThreads
maxIoThreads / minIoThreads
minFreeThreads
minLocalRequestFreeThreads

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

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

<system.net> <connectionManagement> <add address="*" maxconnection="5000" /> <add address = "http://www.habrahabr.ru" maxconnection = "9999" /> <add address = "http://65.53.32.230:88" maxconnection = "240" /> </connectionManagement> </system.net>

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

http(s)://<IP-адрес или Имя сервера>:<Порт>

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

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

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

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

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

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

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

WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors

или

echo %NUMBER_OF_PROCESSORS%

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

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

C:WindowsMicrosoft.NETFramework64v4.0.30319ConfigMachine.config:

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

Приведу настройки конфигурации с нашего веб-сервера <system.web> <processModel autoConfig="False" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="8" /> <httpRuntime minFreeThreads="640" minLocalRequestFreeThreads="96"> </system.web> <system.net> <connectionManagement> <add address = "http://Адрес_сервера_1" maxconnection = "5000" /> <add address = "http://Адрес_сервера_2" maxconnection = "5000" /> </connectionManagement> </system.net>

Важно: после внесения изменений требуется обновить 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

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

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

Заключение

Ссылки

Автор: Nova_M5

Источник

www.pvsm.ru

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

Введение

Предыстория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

maxConnection
maxWorkerThreads / minWorkerThreads
maxIoThreads / minIoThreads
minFreeThreads
minLocalRequestFreeThreads

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

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

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

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

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Machine.config:

Для анализа производительности веб-серверов рекомендую настроить счётчики 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

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

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

Заключение

Ссылки

sohabr.net

Отключить / удалить компоненты IIS - Оптимизация памяти

W2WP.EXE Это процесс, который является частью более широкого спектра услуг IIS, Во многих случаях этот процесс создает проблемы Оперативная память и КПУ из-за высокого потребления ресурсов. Кто IIS не использует этот процесс на нынешней системе не делает ничего, чтобы уменьшить выступления операционной системы.

IIS (Информационные услуги Интернет или Информационный сервер сети Интернет) представляет собой пакет Интернет-услуги с модульной архитектурой разработана серверы продукты Microsoft (Microsoft Windows). IIS является вторым веб-сервер которые используют море в передней dinstanta IISКТК Apache Web / HTTP Server которая в настоящее время лежит в основе самых последних интернет-сайтов. Как Apache, IIS предоставляет разработчиков si администраторы протоколы, такие как Ftp, FTPS, SMTP, NNTPи HTTP / HTTPS.

W3WP.EXE только один модуль этого сложного процесса IIS услуг. Операционные системы Окна 7 этот процесс не должен запускаться при старте или внезапно появляется в списке процессов Диспетчер задач если ваш не использует IIS. Microsoft IIS, включенного в операционных системах 7 список приложений "Windows Features" и IIS пакет должен быть неактивным по умолчанию в Компоненты WindowsОставив на усмотрение пользователя, если он хочет, чтобы пакет был установлен или нет. Если же пакет IIS модулей, установленных на вашем компьютере и в Диспетчер задач Такие процессы происходят W3WP.EXE, inetsrv.exe или другие исполняемые в настоящее %% Windir \ System32 \ Inetsrv \Это лучше удалить. Любая услуга / процесс бесполезным для вас. или гладких функций операционной системыДелает это очень сложная система перспективе операционные занимает оперативной памяти и ресурсов процессора.

Удаление служб Internet Information Services в Windows, 7.

Сейчас любопытно посмотреть, какие модули активны и какие из них работают в системе можно ввести Диспетчер IIS (Пуск> поиск "МИС"> щелкните Internet Information Services (IIS) Manager.

IIS удаления операционной системы Окна 7 так же просто, как удаление Internet Explorer 8, Устройства настольного компьютера или по умолчанию Игры.

1. перейти к Компоненты Windows si снимите флажок следующий Средства управления веб.

2. Нажмите кнопку ОК и дождаться, пока пакет не будет удалено.

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

После перезапуска пакета PC / процесс IIS не будет работать на компьютере во время перезагрузки позволяют настраивать системные изменения. Не передавайте кнопку питания.

Отключение / удаление компонентов IIS - Оптимизация памяти

ru.stealthsettings.com

c# - Оптимизация IIS7 для разработки и отладки.NET

РЕДАКТИРОВАТЬ

Независимо от того, какой тип IIS вы используете, один из лучших способов ускорить работу - создать RAM-диск и указать на него ASP.NET Temporary Files TEMP и особенно ASP.NET Temporary Files. Временные файлы ASP.NET содержат скомпилированные двоичные файлы для ваших страниц. ASP.NET проверяет эту папку при запуске и только перекомпилирует страницы с изменениями. Помещение этой папки на RAM-накопитель увеличит время запуска на порядки. Этот метод описан в нескольких статьях, например. в разделе "Сократите время компиляции/загрузки ASP.NET без какой-либо тяжелой работы "

В качестве дополнительного бонуса вы также уменьшите износ вашего SSD.

оригинал

Для веб-приложений

Похоже, вы настроили свой проект на использование Visual Studio Development Server или IIS Express вместо локальной службы IIS на вашем компьютере. Когда это происходит, происходит значительная задержка, так как Dev Server начинается с нуля.

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

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

Чтобы изменить тип сервера, используемого для отладки, перейдите в веб-приложение "Свойства"> "Веб" и в разделе " Servers ", измените выделение с сервера разработки на локальный IIS. Вам нужно будет создать виртуальный каталог для вашего приложения, но это можно сделать легко, набрав требуемый URL-адрес в текстовом поле Project Url и нажав кнопку "Создать виртуальный каталог".

Для проектов веб-сайтов

Влияние IIS Express/Visual Studio Dev Server на локальный экземпляр IIS выполняется и для проектов веб-сайтов. Файловые веб-сайты по умолчанию используют сервер dev. Процесс перехода на локальную службу IIS отличается. К счастью, это подробно описано в разделе Как указать веб-сервер для веб-проектов в Visual Studio

qaru.site

IIS 7.0: Top 10 Performance Improvements in IIS 7.0

08/22/2016
Время чтения: 21 мин

В этой статье

IIS 7.0

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

Майк Володарский (Mike Volodarsky)

Кратко

Уменьшить место, занимаемое приложением
Уменьшить занимаемую полосу пропускания
Использовать расширенные возможности кэширования

Cодержание

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

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

производительность должна возрасти; но не удивляйтесь, если сразу после переноса приложений на IIS 7.0 этого не произойдет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4) и доступный в центре загрузок iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Более подробно об этом можно узнать в блоге Скотта Гатри (Scott Guthrie) (доступен по адресу go.microsoft.com/fwlink/?LinkId=122514).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Майк Володарский ранее являлся руководителем программы в группе IIS корпорации Майкрософт. Последние пять лет он руководил проектированием и разработкой основных функций ASP.NET 2.0 и IIS 7.0. Теперь он занимается созданием усовершенствованных технологий веб-серверов для высокопроизводительных веб-ферм, использующих IIS 7.0 и Windows Server 2008. Майк является ведущим автором книги IIS 7.0 Resource Kit и часто пишет для журнала MSDN Magazine и в своем блоге по IIS 7.0, mvolo.com.

technet.microsoft.com

Оптимизация работы поисковой системы при помощи ASP.NET 4.0, Visual Studio 2010 и IIS7

Мы еще тег для пользователя, нажмите на кнопку, но тег привязки использует JavaScript заставить обозреватель обратной передачи на сервер. LinkButton отображает это HTML для порождения события щелкните серверной стороны, когда пользователь щелкает ссылку. К сожалению JavaScript обратной передачи перемещения и поиска модули не работают вместе. Связь является эффективно невидимыми для средств поиска, и они никогда не может найти страницу назначения.

Рис. 6 IIS 7 Manager

Так как абстрактный размещение HTML элементы управления ASP.NET на сервере, должны разумно выберите серверных элементов управления. Если требуется полный контроль над разметку HTML в среде ASP.NET, затем следует с помощью платформы ASP.NET MVC. Серверные элементы управления являются verboten, при использовании платформы MVC и инфраструктура и интерфейсы API, находятся в место для работы только разметку HTML.

Если используется веб-форм ASP.NET и оптимизации для поисковых, вы захотите просмотреть источник HTML, созданные элементы управления сервера. Каждый веб-обозреватель выдаст этот параметр. В обозревателе Internet Explorer, используйте представление - >Источник команды. Будьте осторожны с любой элемент управления, отображающий сочетанием HTML и JavaScript в сценариях переходов. Например с AutoPostBack элемента управления DropDownList, используемого свойства равным true будет требовать JavaScript для работы. Если полагаться на автоматической обратной передачи для перехода к новому содержимому можно будет осуществлять содержимое невидимыми для средств поиска.

Очевидно, что доступно AJAX приложений может представлять проблему для поисковых. Элемент управления UpdatePanel и содержимого, созданный вызовы веб-службы из JavaScript не понятное поисковых. Безопасный подход для работы SEO — разместить содержимое в HTML, чтобы сделать его легко обнаруживаемые.

После оптимизировано HTML, ключевые слова и в URL-адреса, как вы измеряете результаты? Хотя рейтинг механизм поиска полномасштабный судьи SEO усилий, было бы замечательно, если найден проблем перед узлом переходит live и механизм поиска обхода содержимого страницы. Хотя Visual Studio может сообщить о проблемах проверку HTML, он не предупреждение о отсутствуют метаданные и Канонический URL. Это задание нового продукта--SEO IIS набор средств.

Рис. 7 Сводка по отчету

Этот набор средств IIS SEO

SEO средств IIS является бесплатной загрузки IIS 7 и доступны из iis.net/extensions/SEOToolkit. Этот нанабор средств средств средств включает обхода механизм, который будет индексировать локальные веб-приложения как механизм поиска и предоставить подробные узла аналитического отчета. нанабор средств средств средств инструментов также можно управлять файлы robots.txt и карты веб-узла. Файл роботов использует стандартный формат сообщить поисковых что исключить из индексирования, пока файлы карты веб-узла могут указывать поисковых содержимого, которые требуется включить. Можно также использовать файлы карты веб-узла определить механизм поиска, приоритет, скорость изменения и Дата изменения ресурса.

Для работы SEO отчет анализа веб-узла является неоценимым. Отчета сообщит все об узле с точки зрения поисковой системы. После установки набора средств, в окне диспетчера IIS 7 появится пункт Анализ узла для ваших узлов, как показано на рис. 6.

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

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

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

Простой и эффективной

Даже при наличии наибольшее содержимого в мире, необходимо сделать видимым для поисковых перевести посетителей содержимого. SEO является практика думать как механизм поиска внесения привлекательность веб-узла программ-обходчиков и ранжирование алгоритмов. Visual Studio 2010 и ASP.NET 4.0 Введение новых функций, чтобы сделать проще работать в .NET 4.0 при IIS SEO SEO набор средств средство фантастические предназначенный для внесения лучше подходит для поисковых веб-узла. С помощью трех средств в сочетании сделать работу SEO простым и эффективным.

K. SCOTT ALLEN является членом технического персонала компании Pluralsight и основатель OdeToCode. Достичь Allen на [email protected] или прочитать его блог по odetocode.com/blogs/scott.

msdn.microsoft.com