В настоящее время вы работаете в автономном режиме; ожидается повторное подключение к Интернету

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

ВНИМАНИЕ! Данная статья переведена с использованием программного обеспечения Майкрософт для машинного перевода и, возможно, отредактирована посредством технологии Community Translation Framework (CTF). Корпорация Майкрософт предлагает вам статьи, обработанные средствами машинного перевода, отредактированные членами сообщества Майкрософт и переведенные профессиональными переводчиками, чтобы вы могли ознакомиться со всеми статьями нашей базы знаний на нескольких языках. Статьи, переведенные с использованием средств машинного перевода и отредактированные сообществом, могут содержать смысловое, синтаксические и (или) грамматические ошибки. Корпорация Майкрософт не несет ответственности за любые неточности, ошибки или ущерб, вызванные неправильным переводом контента или его использованием нашими клиентами. Подробнее об CTF можно узнать по адресу http://support.microsoft.com/gp/machine-translation-corrections/ru.

Эта статья на английском языке: 821268
Проблема
При выполнении вызова веб-служб из приложений Microsoft ASP.NET, могут возникнуть конфликты, низкой производительности и взаимоблокировок. Клиенты могут сообщать перестать отвечать на запросы (или «зависает») или занять очень много времени, чтобы выполнить запросы. Если обнаружена взаимоблокировка, рабочий процесс может быть перезапущен. Может появиться следующее сообщение в журнал событий приложения.
  • При использовании служб информации Интернет (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 на один ЦП.
  • Разрешить обратные вызовы веб службы могут свободно использовать потоков в ThreadPool.
  • Выберите соответствующее значение для параметра maxconnections . Выбор основан на число andAppDomains 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

Пакет обновления 3 для ASP.NET 1.0 и 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="http://65.53.32.230" maxconnection="12"></connectionManagement>
Если код приложения ссылается приложение по доменному имени вместо IP-адреса, параметр должен выглядеть следующим образом:
<connectionManagement>    <add address="*" maxconnection="2">    <add address="http://hostname" maxconnection="12"></connectionManagement>
И, наконец Если приложение размещено на порт, отличный от 80, параметр должен включать нестандартный порт в URI, следующий:
<connectionManagement>    <add address="*" maxconnection="2">    <add address="http://hostname:8080" maxconnection="12"></connectionManagement>
Настройки параметров, описанных ранее в этой статье, все на уровне процесса. Однако этот параметр maxconnection применяется на уровне домена приложения. По умолчанию потому что эта политика применяется на уровне домена приложения, можно создать более двух подключений для определенного IP-адреса из каждого домена приложения в процессе.

executionTimeout

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

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

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

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

Если вы делаете один вызов веб-службы для одного IP-адреса каждой страницы ASPX, корпорация Майкрософт рекомендует использовать следующие параметры конфигурации:
  • Значения параметра maxWorkerThreads и параметр maxIoThreads до 100.
  • Установите значение параметра maxconnection12 *N (где N число процессоров thatyou иметь).
  • Задайте значения для параметра minFreeThreads88 *N а параметр minLocalRequestFreeThreads76 *N.
  • Значение Setthe minWorkerThreads до 50. Помните, что minWorkerThreads отсутствует в файле конфигурации по умолчанию. Его необходимо добавить.
Некоторые из этих рекомендаций подразумевают простую формулу, которая содержит число процессоров на сервере. Переменная, представляющая количество ЦП в формулах N. Для этих параметров Если технология Hyper-Threading включена, необходимо использовать количество логических процессоров вместо число физических процессоров. Например при наличии 4 процессорных сервера с технология Hyper-Threading включена, выберите значение N в формулах будут 8 вместо 4.

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

Например имеется сервер с четырьмя процессорами и технология 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 и низкой производительности, перейдите к следующей блогов Майкрософт:
Ссылки
Для получения дополнительных сведений посетите следующий веб-узел Microsoft Developer Network (MSDN):

Внимание! Эта статья переведена автоматически

Свойства

Номер статьи: 821268 — последний просмотр: 03/15/2015 08:40:00 — редакция: 5.0

Microsoft .NET Framework 2.0, Microsoft ASP.NET 1.1, Microsoft ASP.NET 1.0

  • kbprb kbmt KB821268 KbMtru
Отзывы и предложения