Afirmația, o performanță slabă și blocajelor atunci când face apeluri la consolidare servicii Web dintr-o aplicație de ASP.NET

Traduceri articole Traduceri articole
ID articol: 821268 - View products that this article applies to.
Măriți totul | Reduceți totul

În această pagină

Simptome

Atunci când face apeluri la consolidare servicii Web dintr-o aplicație Microsoft ASP.NET, este posibil să apară afirmația, o performanță slabă și blocajelor. Clientii pot raporta că cererile nu mai răspunde (sau "atarna") sau să ia foarte mult marcă de timp la spre execute. Dacă se suspectează un impas, procesul de lucru poate fi reciclat. Este posibil să primiți următoarele mesaje în jurnal de evenimente aplica?ie.
  • Dacă utilizați Internet Information Services (IIS) 5.0, primiți următoarele mesaje în jurnalul de aplicații:

       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.

  • Dacă utilizați IIS 6.0, primiți următoarele mesaje în jurnalul de aplicații:

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

  • Dacă utilizați IIS 6.0, primiți următoarele mesaje în jurnalul de sistem:

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

Este posibil să primiți următoarea eroare excepție atunci când mesajul face un apel sosit la metoda HttpWebRequest.GetResponse :
"System.InvalidOperationException: Nu erau destui Fire gratuit în obiectul ThreadPool pentru a finaliza operațiunea."
De asemenea, este posibil să primiți următorul mesaj de eroare de excepție în browser:
"HttpException (0x80004005): cerere temporizat out."
Notă Acest articol se aplică, de asemenea, aplicații care face cereri de HttpWebRequest direct.

Cauză

Această problemă poate apărea deoarece ASP.NET limitează numărul fire de lucrător și finalizarea port fire care un apel sosit pot utiliza pentru a executa cereri.

De obicei, un apel sosit la un serviciu web utilizează un fir lucrătorului să execute cod care trimite cererea și un fir de portul finalizarea a primi apel sosit invers la serviciul Web. Cu toate acestea, dacă cererea este redirecționat sau necesită autentificare, apelul poate utiliza cât mai multe două fire de lucrător și două finalizarea port fire. Prin urmare, vă poate de evacuare ThreadPool gestionate atunci când apar mai multe apeluri de consolidare servicii Web în același marcă de timp.

De exemplu, să presupunem că ThreadPool este limitată la 10 fire de lucrător ?i că toate lucrător 10 fire sunt în prezent executarea de cod care așteaptă un apel sosit la spre execute. apel sosit invers nu poate executa, deoarece orice elemente de lucru care sunt în pune în Listă tabel de așteptare așteptare pentru ThreadPool sunt blocate până când un fir devine disponibil.

O altă sursă potențială de controversă este parametrul maxconnection care utilizează spa?iul de nume System.Net pentru a limita numărul de conexiuni. În general, această limită de lucrări cum era de așteptat. Cu toate acestea, în cazul în care multe aplicații să încerce să facă multe cereri de către o singură adresă IP în același marcă de timp, fire poate fi necesar să așteptați pentru o conexiune disponibile.

Rezoluție

Pentru a rezolva aceste probleme, aveți posibilitatea să tune parametrii următori din fișierul Machine.config pentru a se potrivi cel mai bine situația dvs.:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • MaxConnection
  • executionTimeout
Pentru a rezolva cu succes aceste probleme, luați următoarele acțiuni:
  • Limita numărul de cereri de ASP.NET care poate executa la în același marcă de timp la aproximativ 12 pe CPU.
  • Permite Web serviciu callback pentru a utiliza în mod liber fire în ThreadPool.
  • Selectați o valoare corespunzătoare pentru parametrul maxconnections . Selecția de bază pe număr de adrese IP și Uri care sunt utilizate.
Notă Recomandarea de a limita numărul de cereri de ASP.NET-12 fiecare CPU este un pic arbitrară. Cu toate acestea, această limită a dovedit să funcționeze bine pentru cele mai multe aplicații.

maxWorkerThreads și maxIoThreads

ASP.NET utilizează următoarele setări de configurare două pentru a limita numărul maxim de fire de lucrător și finalizarea fire care sunt utilizat:
<processModel maxWorkerThreads="20" maxIoThreads="20">
Parametrul maxWorkerThreads și parametrul maxIoThreads sunt implicit înmulțită cu numărul de procesoare. Pentru exemplu, dacă aveți două procesoare, numărul maxim de fire de lucrător este următoarele:
2 * maxWorkerThreads

minFreeThreads și minLocalRequestFreeThreads

ASP.NET, de asemenea, conține următoarea configurație setări care determină cât de multe fire de lucrător și finalizarea portul fire trebuie să fie disponibile pentru a începe o solicitare de la distanță sau o solicitare de locale:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Dacă nu există suficientă firele folositor, cererea este în așteptare până când sunt suficiente Fire gratuit pentru a face cererea. Prin urmare, ASP.NET va nu executa mai mult de următorul număr de solicitări în același timp:
(maxWorkerThreads*numărul de procesoare)-minFreeThreads
Notă Parametrul minFreeThreads și parametrul minLocalRequestFreeThreads nu sunt implicit înmulțit cu numărul de procesoare.

minWorkerThreads

ASP.NET 1.0 pachet Service Pack 3 și ASP.NET 1.1, ASP.NET, de asemenea, conține următoarea setare configurare care determină cum multe fire de lucrător pot fi disponibili imediat la o distanță de serviciu cerere.
<processModel minWorkerThreads="1">
Fire care sunt controlate de aceasta setare pot fi create la o rata mult mai repede decât fire de lucrător create din CLR implicit "fir-tuning" capabilități. Această setare permite ASP.NET la solicitările de consolidare servicii care pot fi completarea brusc ASP.NET cerere coadă din cauza încetinirea pe o înapoi sfârșitul server, o explozie bruscă de cereri de la clientul final, sau ceva similar care ar provoca o creștere bruscă a numărului de solicitări în coadă. The valoare implicită pentru parametrul minWorkerThreads este 1. Vă recomandăm să seta?i valoarea pentru parametrul minWorkerThreads a valorii.
minWorkerThreads = maxWorkerThreads / 2
implicit, parametrul minWorkerThreads nu este prezent în fie fi?ierul Web.config sau fișierul Machine.config. Această setare este implicit înmulțită cu numărul de Procesoare.

MaxConnection

Parametrul maxconnection determină cât de multe conexiuni pot fi făcute pentru o specifică Adresă IP. Parametrul apare după cum urmează:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Dacă aplicarea codului face referire cererea de nume gazdă în loc de Adresă IP, parametrul ar trebui să apară după cum urmează:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
În cele din urmă, în cazul în care cererea este găzduit pe un port decât 80, parametrul trebuie să includ portul non-standard în URI, similar cu următorul:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
Setările pentru parametrii care sunt discutate mai devreme în acest articol sunt toate la nivelul procesului. Cu toate acestea, Setarea parametrului maxconnection se aplică la nivelul AppDomain. implicit, deoarece această setare se aplică la nivelul AppDomain, aveți posibilitatea să creați maxim de două conexiuni la o anumită adresă IP de la fiecare AppDomain în dumneavoastră procesul.

executionTimeout

ASP.NET utilizează următoarea setare de configurare pentru limită de execu?ie solicitare:
<httpRuntime executionTimeout="90"/>
Aveți posibilitatea să setați această limită utilizând proprietatea Server.ScriptTimeout .

Notă Dacă măriți valoarea parametrului executionTimeout , de asemenea, trebuie să modificați processModel responseDeadlockInterval Setarea parametrului.

Recomandări

Setările care sunt recomandate în această secțiune poate să nu funcționeze pentru toate aplicațiile. Cu toate acestea, următoarele informații suplimentare poate ajuta la face ajustările adecvate.

Dacă fac un apel sosit de consolidare servicii Web la o singură adresă IP la fiecare pagină ASPX, Microsoft recomandă să utilizați următoarele setări de configurare:
  • Setați valorile parametrul maxWorkerThreads și parametrul maxIoThreads la 100.
  • Setați valoarea parametrului maxconnection a 12 *N (în cazul în care N este numărul de procesoare care ai).
  • Setați valorile de parametrul minFreeThreads pentru a 88 *N și de parametrul minLocalRequestFreeThreads pentru a76 *N.
  • Set valoarea minWorkerThreads la 50. Amintiți-vă, minWorkerThreads nu este în fișier de configurare implicit. Trebuie să adăugați-l.
Unele aceste recomandări implica o formulă simplă care implică numărul de procesoare pe un server. Variabilă care reprezintă numărul de procesoare, în formule este N. Pentru aceste setări, dacă aveți hyperthreading activată, trebuie să utilizați numărul de procesoare logice în loc de numărul de procesoare fizice. De exemplu, dacă aveți un server de patru-procesor cu hyperthreading activată, apoi valoarea de N în formulele vor fi 8 în loc de 4.

Notă Când utilizați această configurație, le poate executa maxim 12 ASP.NET solicitări pe CPU în același marcă de timp, pentru că 100-88 = 12. Prin urmare, cel puțin 88 *N lucrător fire și 88 *N finalizarea port fire sunt disponibil pentru alte utilizări (astfel ca pentru Web serviciu callback).

De exemplu, aveți un server cu 4 procesoare și hyperthreading activat. Bazat pe aceste formule, utilizați următoarele valori pentru setările de configurare, care sunt menționate în acest articol.
<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>

De asemenea, atunci când utilizați această configurație, 12 conexiuni sunt disponibile fiecare CPU la o adresă IP pentru fiecare AppDomain. Prin urmare, în următoarele scenariu, foarte putin discordiei se produce atunci când cererile sunt în așteptare pentru nu este epuizată conexiuni și ThreadPool:
  • Web găzduiește doar o singură cerere (AppDomain).
  • Fiecare cerere de o pagină ASPX face o solicitarea serviciului Web.
  • Toate cererile sunt la aceeași adresă IP.
Cu toate acestea, atunci când utilizați această configurație, scenarii care implică una din următoarele va folosi, probabil, prea multe conexiuni:
  • Cererile sunt la mai multe adrese IP.
  • Cererile sunt redirecționate (codul de stare 302).
  • Cereri necesita autentificare.
  • Cererile sunt făcute dintr-uri multiple.
În aceste scenarii, este o idee bună să utilizați o valoare mai mică pentru maxconnection parametri și valori mai ridicate pentru parametrul minFreeThreads și parametrul minLocalRequestFreeThreads .

Stare

Acest lucru comportament este cel proiectat.

Informații suplimentare

Dacă vă confruntați cu o performanță slabă și afirmația pe IIS 7.0 cu ASP.NET, accesa?i următoarele Blogurile Microsoft:
Utilizarea ASP.NET Thread pe IIS 7.5, IIS 7.0 și IIS 6.0

ASP.net atârna în IIS 7.0

Referințe

Pentru mai multe informații, du-te la următorul site Web Rețea Microsoft pentru dezvoltatori (MSDN):
Îmbunătățirea performanțelor ASP.NET

Proprietă?i

ID articol: 821268 - Ultima examinare: 6 februarie 2013 - Revizie: 1.0
Se aplică la:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Cuvinte cheie: 
kbprb kbmt KB821268 KbMtro
Traducere automată
IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât și articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuși, un articol tradus automat nu este întotdeauna perfect. Acesta poate conține greșeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greșeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conținutului sau de utilizarea traducerii necorespunzătoare de către clienții nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 821268

Trimite?i feedback

 

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