Почему очередь запросов высока, даже если выполнение запроса ниже ее предела?

Question

Почему очередь запросов высока, даже если выполнение запроса ниже ее предела?

Мы используем ниже настройки

• Целевая платформа: .Net 3.5 Framework
• Пул приложений:.Net Framework v2.0.50727 с режимом управляемого конвейера - встроенный
• И нет ЦП 8, поэтому maxconcurrentRequestperCPUx8=96
• Оперативная память: 24 ГБ

С настройками по умолчанию в machine.config и aspnet.config

Мы провели тестирование с ACT и взяли счетчики производительности.

ASP.NET Apps v2.0.50727 (_LM_W3SVC_2_ROOT) \ Выполнение запросов

ASP.NET v2.0.50727\ Запросы в очереди

Теперь мы внесли следующие изменения

В aspnet.config

 <system.web>
      <applicationPool maxConcurrentRequestsPerCPU="5000" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
 </system.web>

В machine.config

<system.web>
    <processModel autoConfig="false" maxWorkerThreads="4095" maxIoThreads="4095"    minWorkerThreads="2047" minIoThreads="2047" />
</system.web>

И укажите лимит очереди пула приложений =5000 Теперь у нас намного меньше сравнительной очереди запросов, и высокий запрос выполняется, как показано на снимках экрана ниже!

ASP.NET Apps v2.0.50727 (_LM_W3SVC_2_ROOT) \ Выполнение запросов

ASP.NET v2.0.50727\ Запросы в очереди

Но на удивление средняя. Время отклика в секундах в ACT не улучшилось.

Итак, у меня есть ниже вопросы...

1) Почему существует очередь запросов, даже если выполнение запроса ниже его предела (в моем случае номер CPU x maxconcurrentrequestperCPU = 8 x 12 = 96)?

2) Даже при внесении изменений в aspnet.config, machine.config и предоставлении лимита очереди пула приложений =5000, почему наблюдается очередь запросов?

3) Почему время отклика ACT не улучшилось, так как счетчик выполнения запросов выше?

Любая помощь приветствуется!

Спасибо,

Сандипкумар Гупта

Answer 1

Похоже, вы сделали все, как описано Томасом Л. Марквардтом, и даже увеличили minWorkerThreads и minIoThreads.

Есть интересная часть, касающаяся управления соединением / maxconnection, которая может повлиять на вас

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

Затем он рекомендует

Если ваше приложение ASP.NET использует веб-сервисы (WFC или ASMX) или System.Net для взаимодействия с бэкендом по HTTP, вам может потребоваться увеличить соединение / максимальное управление. Для приложений ASP.NET это ограничено 12 * #CPU функцией autoConfig. Это означает, что в Quad-Proc вы можете иметь не более 12 * 4 = 48 одновременных подключений к конечной точке IP.

И, к сожалению, он добавляет

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