Создание очереди запросов большого рабочего процесса iis7, блокирование процесса aspnet.config и machine.config изменены (узкое место)

Приложение ASP.net 2.0. .NET 2.0 framework IIS7

Я вижу большую очередь «запросов» под опцией «рабочий процесс». Записанное состояние больше всего похоже на запросы аутентификации и выполнения запросов.

Я изменил 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="true"
maxIoThreads="100"              
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"

    minFreeThreads="176" 
    minLocalRequestFreeThreads="152"

Тем не менее, у меня проблема.

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

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

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

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

Рассматриваемый пул приложений ФИКСИРОВАННЫЙ ЗАПРОС настроен на обновление на 50000.

Спасибо за любую помощь. Скотт

быстрое редактирование, чтобы сказать хм, мои разработчики говорят мне, что проект был построен на платформе .net 3.5. Смотря на

C: \ Windows \ Microsoft.NET \ Framework64 \ v3.5

похоже, не существует ASPNET.CONFIG или MACHINE.CONFIG .... есть ли эквивалент 3.5?

после небольшого поиска apparenetly 3.5 использует файлы инфраструктуры 2.0, которые отсутствуют в 3.5.

Итак, вернемся к исходному вопросу, где мое узкое место?

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

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

Основываясь на том, что вы там найдете, вы можете перейти к использованию следующих параметров настройки производительности IIS:

Проверка строк подключения в web.config

По умолчанию максимальный размер пула для строк подключения в файле web.config равен 100, поэтому попробуйте указать что-то большее, например "Max Pool Size=200; Min Pool Size=10; Connect Timeout=45;".

Пример:

<add name="SiteSqlServer" connectionString="Server=mydomain.com;Initial Catalog=myDB;User ID=DB;Password=myDB;Max Pool Size=100;Min Pool Size=10;Connect Timeout=45;" providerName="System.Data.SqlClient" />

Проверка ваших настроек в Aspnet.config

Расположение: C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 и C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727

Пример:

<system.web>
    <applicationPool maxConcurrentRequestsPerCPU="5000" <!-- Default is 12 -->
             maxConcurrentThreadsPerCPU="0" <!-- Default is 0 -->
             requestQueueLimit="5000" <!-- Default is 5000 -->/>
</system.web>

Проверка ваших настроек в machine.config

Расположение: C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG и C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG

processModel

Пример:

<processModel 
   enable="true"
   requestQueueLimit="5000" <!-- Adjust if necessary. Default 5000 -->
   restartQueueLimit="10"  <!-- Adjust if necessary. Default 10 -->
   memoryLimit="60" <!-- Adjust if necessary. Lower for memory leaks. -->
   maxWorkerThreads="100" <!-- Default 20 -->
   maxIoThreads="100" <!-- Default 20 -->
   minWorkerThreads="40" <!-- Default 1 -->
   minIoThreads="30" <!-- Default 1 -->
/>

управление подключением

Пример:

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="100" <!-- Default is 2 --> />
  </connectionManagement>
</system.net>

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

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

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

Вы правы насчет версий фреймворка. .NET 3.0 и 3.5 являются расширениями 2.0. Только до 4.0 появилась совершенно новая версия фреймворка с соответствующим aspnet_isapi.dll и другими файлами ядра.