Твердження, зниження продуктивності і глухі кути, коли ви робити дзвінки до веб-служб із застосунку ASP.NET

Переклади статей Переклади статей
Номер статті: 821268 - Показ продуктів, яких стосується ця стаття.
Розгорнути все | Згорнути все

На цій сторінці

Ознаки

Коли ви робити дзвінки до веб-служба за застосунок Microsoft ASP.NET, можуть виникнути твердження, зниження продуктивності і глухі кути. Клієнти можуть повідомляти про що прохання припинити відповідати на запити (або "повісити") чи зайняти дуже багато часу, щоб виконати. Якщо підозрюється глухий кут, робочий процес може бути відновлений. Може з'явитися таке протокол IMAP у журналі подій застосунків.
  • Якщо використовується інформаційних служб Інтернету (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, ви отримаєте такі протокол IMAP у журналі застосунків:

       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, ви отримаєте такі протокол IMAP до системного журналу:

       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>'.

Винятком помилку може також з'явитися протокол IMAP, коли Ви робите виклик методу HttpWebRequest.GetResponse :
"System.InvalidOperationException: Були не достатньо вільних потоків у ThreadPool об'єкті для завершення в операцію."
Також може з'явитися таке протокол IMAP про помилку виняток у браузері:
"HttpException (0x80004005): запит приурочений з готелю."
Примітка. Ця стаття також відноситься до додатків, які роблять HttpWebRequest запити безпосередньо.

причина

Ця проблема може виникнути ASP.NET обмежує число робочі потоки і завершення порт теми, що виклик клацанням можна використовувати для виконання запити.

Як правило, заклик до веб-служба використовує один робочий потік виконання кодом, яке надсилає запит і один потік порт завершення отримання зворотного виклику веб-служба. Однак, якщо запит буде перенаправлено чи вимагає ідентифікації, виклику може використовувати як дві робочі потоки і два завершення порт теми. Таким чином, може вичерпати керованих ThreadPool коли кілька викликів служби Web місце в той же Вільний час.

Наприклад, припустимо, що в ThreadPool обмежується 10 робочі потоки, і що всі 10 робочі потоки в даний Вільний час виконання коду, який є очікування на виконання. Зворотного виклику ніколи не можна виконати, тому, що будь-який робочих елементів, які є у черзі на ThreadPool заблоковано, поки потік стає доступною.

Ще один потенційний джерелом розбрату є параметр maxconnection , який System.Net простір імен використовує обмежити кількість підключень. Як правило, це обмеження працює правильно. Однак, якщо багато програм намагаються зробити багато запити до однієї IP адреси в той же Вільний час, теми можуть мати чекати наявні підключення.

Розв'язанн

Щоб вирішити ці проблеми, можна налаштувати такі параметри у файлі Machine.config, щоб найкращим чином відповідають ситуації:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • MaxConnection
  • executionTimeout
Щоб успішно вирішити ці проблеми, виконайте такі дії:
  • Обмежити кількість ASP.NET запитів, які можна виконати в одночасно до приблизно 12 за CPU.
  • Дозволити зворотні виклики застосунок-служба 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">
Теми які контролюються за допомогою цього параметра можна створити набагато більш швидкими темпами, ніж робочі потоки, створених за до загальномовне середовище виконання за промовчанням "потік тюнінг" можливості. Цей параметр дає змогу ASP.NET на застосунок-служба запити, які можуть бути раптом заповнення черги запит ASP.NET зв'язок "один-до-одного" з уповільненням на задньому кінці сервер, раптової запити від клієнта кінця, або щось подібне що б заподіяти різким зростанням кількості запитів у черзі. На значення за промовчанням для параметра 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 застосовується до AppDomain рівня. За промовчанням тому що цей параметр застосовується до AppDomain рівня, можна створити максимум двох підключень до певної IP-адреси з кожного AppDomain у вашому процес.

executionTimeout

ASP.NET використовує такий параметр конфігурації для обмежити Вільний час виконання запиту:
<httpRuntime executionTimeout="90"/>
Це обмеження також можна встановити за допомогою властивості Server.ScriptTimeout .

Примітка. Якщо ви збільшуєте значення параметра executionTimeout , також можливо змінювати processModel responseDeadlockInterval параметрів налаштування.

Рекомендації

Настройки, які рекомендували в цьому розділі може не працювати для всі програми. Однак, додаткові відомості допоможуть вам Внесіть відповідні зміни.

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

Примітка. При використанні цієї конфігурації, ви можете здійснювати максимум 12 ASP.NET запитів за CPU в той же Вільний час тому, що 100-88 = 12. Таким чином, принаймні 88 *N працівник теми та 88 *N завершення порт теми є для інших використовує (таких як зворотного виклику веб-служби).

Наприклад, у вас є сервер з чотирьох процесорів і hyperthreading увімкнуто. На основі цих формул, ви б використовувати такі значення для в параметри конфігурації, які згадані в цій статті.
<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-адресу для кожного AppDomain. Таким чином, в таких сценарій, дуже мало розбрату виникає, коли на чекають запити підключення та на ThreadPool не вичерпані:
  • Інтернет хости лише один застосунок (AppDomain).
  • Кожен запит на сторінці ASPX робить одного запит на змінення веб-служба.
  • Всі запити мають ту ж адресу IP.
Однак, при використанні цієї конфігурації, сценарії які передбачають одним з таких, ймовірно, використовувати занадто багато підключень:
  • Запити мають кілька IP-адрес.
  • Запити виконуються перенаправлені (302 статус кодексу).
  • Запити вимагають автентифікації.
  • Запити зроблені з декількох програмні домени.
У цих сценаріях це гарна ідея, щоб використовувати менше значення для параметр maxconnection і більш високі значення для параметра minFreeThreads і параметр minLocalRequestFreeThreads .

Стан

Це ситуацію передбачено.

Додаткові відомості

Якщо ви відчуваєте бідних продуктивності і твердження у службах IIS 7.0 разом з ASP.NET, перейдіть на наступні блоги Microsoft:
сценарій виконання ASP.NET нитку на IIS 7.5, IIS 7.0 і IIS 6.0

ASP.net повісити в IIS 7.0

Посилання

Щоб отримати додаткові відомості перейдіть на веб-сайт корпорації Microsoft Developer Network (MSDN):
Підвищення продуктивності ASP.NET

Властивості

Номер статті: 821268 - Востаннє переглянуто: 6 лютого 2013 р. - Редакція: 1.0
Застосовується до:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Ключові слова: 
kbprb kbmt KB821268 KbMtuk
Машинний переклад
УВАГА! Цю статтю переклала програма машинного перекладу Microsoft, а не людина. Корпорація Microsoft пропонує вам як машинні переклади, так і переклади фахівців, щоб Ви мали доступ до всіх статей бази знань рідною мовою. Проте стаття, яку переклав комп’ютер, не завжди бездоганна. Вона може містити лексичні, синтаксичні або граматичні помилки. Так само помиляється іноземець, спілкуючись вашою рідною мовою. Корпорація Microsoft не несе відповідальність за жодні неточності, помилки або шкоду, завдану неправильним перекладом змісту або його використанням з боку користувачів. Крім того, корпорація Microsoft часто оновлює програму машинного перекладу.
Клацніть тут, щоб переглянути цю статтю англійською мовою: 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