Состязание за низкой производительности и взаимоблокировок при выполнении запросов веб-службы из ASP.NET приложений

Переводы статьи Переводы статьи
Код статьи: 821268 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Проблема

Когда выполнять вызовы веб-служб XML из приложения ASP.NET приложения, могут возникнуть конфликты, низкой производительности и взаимоблокировок. Клиентам может сообщить, что запросы перестать отвечать на запросы (или «зависает») или занять очень долго. Если обнаружена взаимоблокировка, рабочий процесс может быть повторно. Может появиться следующее сообщение в журнал событий приложения.
  • При использовании служб IIS (IIS) 5.0, появиться следующие сообщения событий приложения Журнал:

       Event Type:     Error
       Event Source:   ASP.NET 1.0.3705.0
       Event Category: None
       Event ID:       1003
       Date:           5/4/2003
       Time:           6:18:23 PM
       User:           N/A
       Computer:       <ComputerName>
       Description:
          aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
          It did not send any responses for pending requests in the last 180 seconds.

  • При использовании IIS 6.0, появляется следующее сообщения в журнале событий приложений:

       Event Type:     Warning
       Event Source:   W3SVC-WP
       Event Category: None
       Event ID:       2262
       Date:           5/4/2003
       Time:           1:02:33 PM
       User:           N/A
       Computer:       <ComputerName>
       Description:
          ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
          unhealthy for the following reason: 'Deadlock detected'.

  • При использовании IIS 6.0, появляется следующее сообщения в журнале событий системы:

       Event Type:     Warning
       Event Source:   W3SVC
       Event Category: None
       Event ID:       1013
       Date:           5/4/2003
       Time:           1:03:47 PM
       User:           N/A
       Computer:       <ComputerName>
       Description:
          A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
          The process id was '<xxxx>'.

Также может появиться следующее сообщение об ошибке исключения сообщения при сделать вызов HttpWebRequest.GetResponse метод:
"System.InvalidOperationException: Не хватает свободных потоков объекта ThreadPool для завершения Операция".
Кроме того, может появиться следующее сообщение об ошибке исключения в обозревателе:
"HttpException (0x80004005): время ожидания запроса недостаточно.»
Примечание Эта статья также применима к приложениям, которые делают HttpWebRequest запросы напрямую.

Причина

Эта проблема может возникать, если ASP.NET ограничивает количество рабочие потоки и потоки порта завершения, вызов можно использовать для выполнения запросы.

Как правило использует один рабочий поток для вызова веб-службы выполнение кода, который отправляет запрос и потока порта завершения одного получаете обратный вызов веб-службы. Однако если запрос перенаправление или требует проверки подлинности, вызов может использовать до двух рабочих и двумя потоками порта завершения. Таким образом может использовать управляемый ThreadPool при возникновении нескольких вызовов веб-служб в то же время.

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

Это еще один возможный источник конфликта MaxConnection параметр, System.NET пространство имен используется для ограничения числа подключений. Как правило, Это ограничение работает надлежащим образом. Однако если многие приложения пытаются сделать много запросы к одному IP-адресу, в то же время потоки иногда нужно подождать для доступное подключение.

Решение

Чтобы устранить эти проблемы, можно настроить следующие параметры в файле Machine.config для наилучшего соответствия ситуации:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • MaxConnection
  • executionTimeout
Успешно решить эти проблемы, выполните следующие действия.
  • Ограничьте число ASP.NET запросы, которые могут выполняться на то же время приблизительно 12 каждого Процессора.
  • Разрешить обратные вызовы службы Web свободно использовать потоки ThreadPool.
  • Выберите соответствующее значение MaxConnections параметр. Базировать свой выбор на число IP-адресов и Домены приложений, которые используются.
Примечание Рекомендация для ограничения числа ASP.NET запросы 12 для Процессора немного произвольный. Тем не менее это ограничение доказало подходят для Большинство приложений.

maxWorkerThreads и maxIoThreads

ASP.NET использует следующие две настройки Чтобы ограничить максимальное число рабочих потоков и потоков завершения используется:
<processModel maxWorkerThreads="20" maxIoThreads="20">
В maxWorkerThreads параметр и maxIoThreads параметр неявно умножаются на количество процессоров. Для пример, при наличии двух процессоров, максимальное число рабочих потоков — следующее:
2 * maxWorkerThreads

minFreeThreads и minLocalRequestFreeThreads

ASP.NET также содержит следующие конфигурации параметры, определяющие, сколько рабочих потоков и завершение порт потоков должен быть доступен для запуска запроса удаленного или локального запроса:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Если нет достаточных потоков доступны, запрос находится в очереди пока достаточно потоки могут использоваться для выполнения запроса. Таким образом ASP.NET будет в то же время выполняется более, чем следующие запросы:
(maxWorkerThreads*Число ЦП)-minFreeThreads
Примечание В minFreeThreads параметр и minLocalRequestFreeThreads параметр не умножаются неявно количество ЦП.

minWorkerThreads

По состоянию на ASP.NET версии 1.0 с пакетом обновления 3 и ASP.NET 1.1, ASP.NET также содержит следующие параметры конфигурации, который определяет, каким образом Многие рабочие потоки могут доступны немедленно дистанционного обслуживания запрос.
<processModel minWorkerThreads="1">
Потоки управляемых этот параметр может быть создан с максимально возможной скоростью, чем рабочие потоки, созданные из среды CLR по умолчанию «поток настройки» возможности. Этот параметр позволяет ASP.NET для обслуживания запросов, которые могут быть внезапно заполнения ASP.Длина очереди NET запросов из-за slow-down на задней стороне сервер, внезапное пакетов запросов от конца клиента или что-то подобное Внезапное увеличение число запросов, которые могут привести в очереди. В значение по умолчанию для minWorkerThreads аргумент принимает значение 1. Рекомендуется устанавливать значение для minWorkerThreads параметр указанный ниже параметр.
minWorkerThreads = maxWorkerThreads / 2
По умолчанию minWorkerThreads параметр не указан в файле Web.config или в файле Machine.config. Этот параметр неявно умножается на число ЦП.

MaxConnection

В MaxConnection параметр определяет, сколько невозможно подключиться к IP-адрес. Параметр выглядит следующим образом:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="65.53.32.230" maxconnection="12">
</connectionManagement>
Настройка параметров, описанных ранее в этом статьи, все на уровне процесса. Тем не менее MaxConnection параметр применяется на уровне домена приложения. По умолчанию так как этот параметр применяется на уровне домена приложения, можно создать до два подключения к IP-адрес из каждого домена приложения, в вашем процесс.

executionTimeout

ASP.NET использует следующие параметры конфигурации для Максимальное время выполнения запроса:
<httpRuntime executionTimeout="90"/>
Это ограничение можно также установить с помощью Server.ScriptTimeout свойство.

Примечание При увеличении значения executionTimeout параметр, также необходимо изменить processModel responseDeadlockInterval значения параметра.

Рекомендации

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

Если При создании одного вызова веб-службы для одного IP-адреса из каждой страницы ASPX Корпорация Майкрософт рекомендует использовать следующие параметры конфигурации:
  • Задайте значения maxWorkerThreads параметр и maxIoThreads параметр 100.
  • Установить значение MaxConnection параметр 12 *N (где N количество процессоров, у вас есть).
  • Задайте значения minFreeThreads параметр 88 *N и minLocalRequestFreeThreads параметр76 *N.
  • Набор значение minWorkerThreads Кому 50. Помните, что minWorkerThreads не найден в файле конфигурации по умолчанию. Необходимо добавить его.
Некоторые Эти рекомендации включают в себя простую формулу, которая включает в себя номер ЦП на сервере. Переменная, которая представляет число процессоров в формулы — N. Для этих параметров, если технология Hyper-Threading включена, необходимо использовать число логических процессоров, а не число физических процессоров. Например, если технология Hyper-Threading включена, затем с 4 процессорных сервера значение N в формулах 8 Вместо 4.

Примечание При использовании этой конфигурации может выполнять более 12 ASP.NET запросы каждого Процессора в то же время, поскольку 100-88 = 12. Таким образом по крайней мере 88 *N Исполнитель потоки и 88 *N потоками порта завершения доступные для других используется (например, для обратных вызовов Web service).

Например у вас есть сервер с четырьмя процессорами и технология Hyper-Threading включено. В зависимости от этих формул можно использовать следующие значения для параметры конфигурации, описанные в этой статье.
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

Кроме того, при использовании этой конфигурации 12 подключения доступны для Процессора на IP-адрес для каждого домена приложения. Таким образом в следующий сценарий, очень мало конкуренции возникает при ожидании запросов подключения и ThreadPool не закончатся:
  • Веб содержит только один приложения (AppDomain).
  • Каждый запрос в ASPX страниц делает одну веб-службу запрос.
  • Все запросы, одним IP-адресом.
Тем не менее при использовании этой конфигурации, сценарии, включающие одно из следующих скорее всего будет использовать слишком много подключений:
  • Запросы могут несколько IP-адресов.
  • Перенаправленный (код состояния 302), запросы.
  • Запросы требуют проверки подлинности.
  • Запросов с несколькими доменами приложений.
В таких случаях рекомендуется использовать меньшее значение для очередь MaxConnection параметр и более высокие значения для minFreeThreads параметр и minLocalRequestFreeThreads параметр.

Статус

Это поведение является особенностью.

Дополнительная информация

Если вы столкнетесь с низкой производительности и конкуренции на IIS 7.0 с ASP.NET, см. ниже блоги Майкрософт:

ASP.Использование потоков NET на IIS 6.0 и 7.0
http://blogs.MSDN.com/tmarq/Archive/2007/07/21/ASP-NET-Thread-Usage-ON-IIS-7-0-and-6-0.aspx
Зависание ASP.NET в IIS 7.0
http://blogs.MSDN.com/webtopics/Archive/2009/02/13/ASP-NET-hang-in-IIS-7-0.aspx

Ссылки

Для получения дополнительных сведений посетите следующие корпорации Майкрософт Developer Network (MSDN) веб-узла:
http://msdn2.Microsoft.com/en-us/library/ms998549.aspx

Свойства

Код статьи: 821268 - Последний отзыв: 15 июня 2011 г. - Revision: 4.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Ключевые слова: 
kbprb kbmt KB821268 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:821268

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com