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

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



Введение


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

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

Предыстория
1. Параметры конфигурации IIS
2. Настройка ASP.NET
3. Рекомендации по оптимизации базовой конфигурации
Дополнительно
Заключение
Ссылки

Предыстория


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

  1. maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
  2. maxIoThreads = 100
  3. maxConnection = 12 * N
  4. minFreeThreads = 88 * N
  5. 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.

Ссылки


  • +24
  • 69,6k
  • 6
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 6

    +2
    Имхо, приведенная стратегия — это не оптимизация производительности, а бездумное перераспределение ресурсов. Если на сервере комплексная система или несколько систем, то дав больше возможностей отдельно взятому пулу другие можно поставить колом))

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

    Если начинаются «зависания», то начать, мне кажется, стоит с определения источника проблемы. Первый шаг — тот же IIS Failed Request Tracing, который разжевывает все этапы прохождения запросов и соответствующие тайминги. Активно применяется и для исследования проблем производительности.
      +2
      >Имхо, приведенная стратегия — это не оптимизация производительности, а бездумное перераспределение ресурсов.

      Не согласен, очень часто бутылочным горлышком является именно maxConnections.
      Здесь описано не бездумное перераспределение ресурсов, а тюнинг. Разработчики приложений сами должны оценить — подойдут ли им значения по умолчанию, которые рекомендует MS или использовать свои.

      >Если начинаются «зависания», то начать, мне кажется, стоит с определения источника проблемы. Первый шаг — тот же IIS Failed Request Tracing, который разжевывает все этапы прохождения запросов и соответствующие тайминги. Активно применяется и для исследования проблем производительности.

      В первую очередь стоит все таки обратить внимание на счетчики производительности, а не IIS Freb логи. Они вам например не покажут, что cpu загружен на 100%.
        0
        Не согласен, очень часто бутылочным горлышком является именно maxConnections.

        На основании чего сделаны такие выводы? Я бы на Вашем месте, прошелся по ссылкам, которые привел ТС. Хоть им больше 10 лет и касаются в основном IIS 6 + .NET 1.0, но общие концепции оптимизации там приведены хорошо и настройка пула предваряется немалым количеством предварительных мероприятий.

        Здесь описано не бездумное перераспределение ресурсов, а тюнинг.

        Я апеллировал к заголовку статьи, где написано оптимизация. Я думаю, разницу между оптимизацией и тюнингом не надо объяснять. Следующий вопрос — тюнинг для каких целей? Максимизации количества пользователей? Минимизации TTFB/TTLB? Минимизации потребляемых ресурсов? Если вы занимались настройкой высоконагруженного IIS, то должны знать, что поднятые воркеры, раздутая очередь не даются бесплатно. RPS может вырасти, но какой ценой.

        В первую очередь стоит все таки обратить внимание на счетчики производительности, а не IIS Freb логи. Они вам например не покажут, что cpu загружен на 100%.

        Лог отвечает на вопрос, что именно нагружает, нагружает ли вообще, в IIS ли дело. После этого я могу поставить нужный счетчик на нужный объект или понять, что счетчики мне вообще не нужны, что надо профилировать приложение, собирать wait statistics с sql-сервера и т.п. Счетчик на загрузку CPU… ну узнали Вы, что он загружен. Что дальше? Я знал о том, что некоторый компонент системы (не обязательно CPU) нагружен еще до того, как начал оптимизацию.
          +2
          >На основании чего сделаны такие выводы? Я бы на Вашем месте, прошелся по ссылкам, которые привел ТС. Хоть им больше 10 лет и касаются в основном IIS 6 + .NET 1.0, но общие концепции оптимизации там приведены хорошо и настройка пула предваряется немалым количеством предварительных мероприятий.

          К сожалению я не смотрел приведенные ссылки. Но могу например сказать, что до 4го фреймворка дефолтовое значение параметра maxConnections было равно 2. Сейчас все приведенные выше параметра по дефолту расчитываются исходя из количество ядер процессора. Таким образом статья актуальна)
          Почему я привел пример с maxConnections? Просто я обычно работал с ASP.NET приложениями, которые выступали клиентам к множеству внешних удаленных сервисов.

          >Следующий вопрос — тюнинг для каких целей?

          Так почитайте раздел «предыстория». Если в кратце, то как я понимаю, автор статьи столкнулся с проблемой, когда при превышении какой то определенного числа пользователей, сервер становился неработоспособным. При этом загрузка CPU, памяти и других аппаратных ресурсов оставалась в норме.
          Профлирование серверного когда не выявило проблем.
          А вот например снятие Full User Dump с процесса w3wp показало, что нет свободных хенделеров для обработки всей очереди http реквестов, или например в дампе наблюдается большая очередь коннектов на внешний бекенд сервис. Это конечно я утрирую. Т.к. автор не указал точной причины, почему же все таки было принято решение менять настройки апп пула и asp.net приложения.

          >cчетчик на загрузку CPU… ну узнали Вы, что он загружен. Что дальше? Я знал о том, что некоторый компонент системы (не обязательно CPU) нагружен еще до того, как начал оптимизацию.

          Да любой профайлер Вам в помощь) Например dotTracePerfomance, Подключаетесь к процесс w3wp, проводите нагрузочное тестирование, и определяете, что грузит процессор. Интересует именно %UserTime, всякие сериализации, десериализации, вычисления и тп.

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

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

      В данном случае следует предостеречь от слишком буквального понимания слова «немедленно». Добавление новой пачки из min[тип_пула]Threads тредов в пул происходит раз в 500 миллисекунд (при дефолтных значениях это 2 потока в секунду).
      Поэтому при слишком низких значениях этих параметров холодный старт сервиса (например после ресайклинга апп пула) его прогрев и выход на расчетную производительность может занят значительное время. Подробности можно почитать по ссылке WCF scales up slowly with bursts of work
      В случае хостинга WCF сервиса в IIS это приводит к интересным спецэффектам.

      P.S. Попытка обнаружить это с помощью профайлера не дает никаких результатов. А вот мониторинг системных счетчиков рисует очень наглядную картину.
        0
        dreik, вы указали важный момент, на который стоит обратить внимание и ссылка очень хорошая :)
        Однако всё таки в данном случае слово «немедленно» нужно понимать буквально.
        Поясню: параметры minIoThreads/minWorkerThreads необходимо задавать для обеспечения работоспособности приложения в случае, когда происходит «взрыв нагрузки» (Burst Load), т.е. количество пользователей возрастает по экспоненте. Если до часа «Х» нагрузка на сайте была невысокая, то в пуле имеется небольшое количество потоков. Таким образом, CLR ThreadPool используя собственный алгоритм распределения потоков может не иметь достаточно времени, чтобы достичь оптимального уровня потоков, т.к. на создание пары новых потоков в пуле уходит около 1сек. Установка параметров minIoThreads/minWorkerThreads позволяет пулу справиться с возросшей нагрузкой в штатном режиме, т.к. минимальное заданное количество «Worker» и «IO» потоков будут созданы и использованы пулом «немедленно».
        Причём, начиная с .NET Framework 4, пул потоков создает и уничтожает потоки в целях оптимизации производительности, поэтому количество текущих потоков в пуле может быть ниже минимального заданного значения minIoThreads/minWorkerThreads. Однако по требованию необходимые потоки для пула могут быть созданы очень быстро до минимальных значений, а при снижении нагрузки они опять удаляются. На MSDN в разделе ThreadPool Class можно починать подробнее про это.

        p.s. В реальной жизни наглядный пример такой ситуации — это получение зарплаты/премии сотрудниками какой-нибудь крупной компании в определённое время, когда все спешат на сайт побыстрее увидеть, сколько же им начислили деньжат ))

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

      Самое читаемое