Как ASP.NET определяет, стоит ли помещать запрос в очередь или нет?

Question

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

Answer 1

Я занимался исследованиями, и я считаю, что нашел приемлемый ответ. Мой первоисточник - эта статья: http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx

Как я понимаю, есть два основных способа регулирования обработки запросов. Первым является свойство MaxConcurrentRequestsPerCPU. До .NET 4 по умолчанию было установлено значение 12. В .NET 4 оно было изменено на 5000. Для асинхронных запросов они хотели многое разрешить, а для синхронных запросов они считают, что ASP.NET ThreadPool будет достаточно эффективно регулировать синхронные запросы. Вторым, конечно, является сам ThreadPool. После того, как ASP.NET отправит запрос туда, он может решить, когда он пойдет.

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

Если вы выполняете синхронную обработку и блокировку веб-вызовов в течение длительных периодов времени, гораздо более вероятно, что вы столкнетесь с этими ограничениями. MaxConcurrentRequestsPerCPU - это то, на что нужно обращать внимание до .NET 4, но все еще есть ThreadPool.

Тестирование производительности
Я собрал простой тест, чтобы увидеть, как работает это регулирование. У меня есть простая страница с вызовом Thread.Sleep () 500 мс. Один хост-компьютер выполняет одновременно 800 асинхронных запросов, а рабочий компьютер, на котором работает ASP.NET, обрабатывает их все. Результаты были интересны:

.NET 3.5, без изменений: 46 секунд. Видел 9 рабочих потоков с помощью проводника процессов.
.NET 3.5 с MaxConcurrentRequestsPerCPU, установленным в 5000: 46 секунд. 9 рабочих потоков.
.NET 4: 42 секунды или 13 секунд при перегреве. Пила около 35 рабочих потоков постепенно создаются.
.NET 4, асинхронный: 3 секунды

Несколько замечаний:

• MaxConcurrentRequestsPerCPU не получил удар. Похоже, это было ограничение самого ThreadPool.
• .NET 3.5, похоже, неохотно создает новые потоки для обработки синхронных запросов. .NET 4 намного лучше справляется с нагрузкой.
• Асинхронный по-прежнему лучший на милю страны.

Answer 2

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

Максимальный пул потоков по умолчанию 20 с минимальным свободным числом 8, что означает, что система будет выполнять только 12 запросов, выполняемых до того, как новые запросы будут поставлены в очередь. Максимальное количество потоков умножается на количество ядер, а минимальное количество потоков - нет, поэтому по умолчанию будет разрешено 32 запроса к двухъядерному блоку до его очереди.

А что касается оставшегося процессора, ASP.NET не отслеживает это. Это просто о количестве используемых потоков. Эти потоки могут быть заблокированы из-за доступа к диску, результатов передачи БД в сетевом доступе или просто из-за Thread.Sleep, который все равно будет вносить свой вклад в новые запросы, поступающие в очередь, даже если ЦП не загружен.

Более подробная информация доступна в книге MS Patterns & Practices по производительности. Это относится к IIS6 / .NET 1.1, но концепции все еще остаются. http://msdn.microsoft.com/en-us/library/ff647787.aspx#scalenetchapt06_topic8

Переконфигурирование для IIS7 / .NET 2+: http://msdn.microsoft.com/en-us/library/e1f13641.aspx