Узкое место в рабочем процессе IIS 7, большое количество ожидающих запросов в пуле приложений ASP.NET 3.5 + 2.0 - PullRequest
Новая
       42

Узкое место в рабочем процессе IIS 7, большое количество ожидающих запросов в пуле приложений ASP.NET 3.5 + 2.0

4 голосов
/ 15 апреля 2011

Я использую ASP.NET 2.0, .NET 2.0 Framework и IIS 7. Я вижу, что большая очередь «запросов» появляется под опцией «рабочий процесс».Записанное состояние выглядит как Authenticate Request и Execute Request Handles больше, чем что-либо еще.

Я изменил aspnet.config в C:\Windows\Microsoft.NET\Framework64\v2.0.50727 (32-битный путь и 64-битный путь), чтобы включить: 

maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"

Я изменил machine.config в C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG (32-битный и 64-битный путь), чтобы включить: 

autoConfig="false"
maxIoThreads="100"
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"
minFreeThreads="176"
minLocalRequestFreeThreads="152"

Тем не менее я получаю эту проблему.

Проблемапроявляется в виде большого количества запросов в очереди рабочего процесса.

Количество текущих подключений к веб-сайту отображает 500 при возникновении этой проблемы.Я не думаю, что видел одновременных подключений более 500 без этой проблемы.

Веб-приложение замедляется, как блок запросов.

Обновление пула приложений разрешается на некоторое время (как и ожидалось)поскольку нагрузка распределяется между двумя пулами.

Для рассматриваемого пула приложений FIXED REQUEST установлено обновление на 50000.

Примечание: .NET 3.5 framework использует appnet 2.0 framework и конфигурацию машиныфайлы, я считаю.

Ресурсы сервера (ЦП, ОЗУ) используются не в полной мере.

Ответы [ 3 ]

3 голосов
/ 17 апреля 2011

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

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

После того, как вы захватили этот дамп, вы хотите загрузить его в WinDBG + SOS и начать отслеживать виновника.

У Тесс есть отличная серия лабораторных работ о том, как использовать эти инструменты для достижения максимального эффекта:

.NET Debugging Demos - Информация и инструкции по настройке

Если вы можете, то вы также можете прикрепить к приложению профилировщик (например, Performance Profiler от RedGate, чтобы попытаться выяснить причину.

1 голос
/ 17 августа 2011

Закончено увеличение рабочих процессов с 1 до 2 (веб-сад). Проблема не повторялась, поскольку, хотя они и использовали сеансы, но в течение месяца не было сообщений о проблемах сеансов от конечных пользователей.

ИЗМЕНЕНО В ДОБАВИТЬ:

Конкретная проблема была связана с генерацией чрезвычайно больших отчетов CSV, которые обрабатываются на стороне сервера рабочего процесса, а не как ошибка, просто так, как она работает. HTML-отчеты в порядке, XML-преобразование передается на стороне клиента.

Разделение рабочих процессов решало проблемы до тех пор, пока преобразование xver-стороны на xml-преобразование в csv-файл не может быть передано процессу добавления, что устранит любое влияние со стороны других пользователей. Было просто до размера файлов / количества строк, с которыми мы работали при создании отчетов CSV.

1 голос
/ 15 апреля 2011

Следуйте статье базы знаний http://support.microsoft.com/kb/821268 и сообщите мне, если проблема не устранена.

Вы также можете попробовать трассировку FREB в IIS 7. http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

...