Conflicten, slechte prestaties en impasses wanneer u webservices aanroepen vanuit een ASP.NET-toepassing

Symptomen

Als u webservices aanroepen vanuit een Microsoft ASP.NET-toepassing, kunnen er conflicten, slechte prestaties en impasses. Clients kunnen melden dat de aanvragen niet meer reageert (of 'loopt vast') of zeer lang duren om uit te voeren. Indien een impasse wordt vermoed, kan het werkproces worden gerecycled. De volgende berichten wordt in het logboek voor toepassingsgebeurtenissen.
  • Als u Internet Information Services (IIS) 5.0 gebruikt, worden de volgende berichten in het toepassingslogboek:
  • Als u IIS 6.0 gebruikt, worden de volgende berichten in het toepassingslogboek:
  • Als u IIS 6.0 gebruikt, worden de volgende berichten in het systeemlogboek:
Ook wordt u volgende Uitzonderingsfoutbericht als u een aanroep van de methode HttpWebRequest.GetResponse :
"System.InvalidOperationException: Er zijn onvoldoende threads in de ThreadPool-object om de bewerking te voltooien."
Ook verschijnt het volgende foutbericht van het type uitzondering in de browser:
"HttpException (0x80004005): time-out bij."
Opmerking In dit artikel geldt ook voor toepassingen die HttpWebRequest verzoeken rechtstreeks maken.

Oorzaak

Dit probleem treedt op omdat ASP.NET beperkingen hanteert voor het aantal worker-threads en poort-threads dat een gesprek gebruiken kunt voor het uitvoeren van aanvragen.

Een aanroep van een webservice gebruikt meestal één worker-thread voor het uitvoeren van de code die de aanvraag verzendt en één poort-thread voor het ontvangen van de callback van de webservice. Als de aanvraag wordt doorgestuurd of verificatie vereist is, kan het gesprek gebruiken twee worker-threads en twee poort-threads. Daarom kunt u de beheerde ThreadPool uitlaatgassen wanneer meerdere aanroepen naar een webservice op hetzelfde moment plaatsvinden.

Stel dat de ThreadPool is ingesteld op maximaal 10 worker-threads en dat alle 10 de threads code die wacht op een callback worden momenteel uitgevoerd. De callback kan dan nooit plaatsvinden, omdat alle werkitems die in de wachtrij de ThreadPool worden geblokkeerd totdat er een thread vrijkomt.

Een andere mogelijke oorzaak van een conflict is de parameter maxconnection die door de naamruimte System.Net wordt gebruikt om het aantal verbindingen beperken. Over het algemeen werkt deze parameter zoals verwacht. Echter, als veel toepassingen probeert te veel aanvragen naar een enkel IP-adres op hetzelfde moment, threads wellicht wachten op een beschikbare verbinding.

Oplossing

Om deze problemen oplossen, kunt u de volgende parameters in het bestand Machine.config aan te passen afstemmen:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
Om deze problemen worden opgelost, neemt u de volgende acties:
  • Beperk het aantal ASP.NET-aanvragen dat tegelijkertijd tot ongeveer 12 per processor kan worden uitgevoerd.
  • Webservice-callbacks gebruik van threads in de ThreadPool.
  • Selecteer een geschikte waarde voor de parameter maxconnections . Uw selectie baseren op het aantal IP-adressen en AppDomains dat wordt gebruikt.
Opmerking Beperk het aantal ASP.NET-aanvragen tot 12 per processor in de aanbeveling is een beetje willekeurig. Deze limiet is echter gebleken geschikt voor de meeste toepassingen.

maxWorkerThreads en maxIoThreads

ASP.NET gebruikt de volgende twee configuratie-instellingen te beperken, het maximum aantal worker-threads en poort-threads worden gebruikt:
<processModel maxWorkerThreads="20" maxIoThreads="20">
De parameters maxWorkerThreads en maxIoThreads worden impliciet vermenigvuldigd met het aantal processors. Bijvoorbeeld als twee processors hebt, kunt u is het maximum aantal worker-threads de volgende:
2*maxWorkerThreads

minFreeThreads en minLocalRequestFreeThreads

ASP.NET bevat ook de volgende configuratie-instellingen die hoeveel worker-threads en poort-threads beschikbaar zijn bepalen moeten voor een externe of lokale aanvraag starten:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Als er onvoldoende threads beschikbaar zijn, de aanvraag in de wachtrij geplaatst totdat er de aanvraag te doen. Daarom wordt ASP.NET niet uitgevoerd meer dan het volgende aantal aanvragen tegelijkertijd:
(maxWorkerThreads*aantal processors)-minFreeThreads
Opmerking De parameters minFreeThreads en minLocalRequestFreeThreads worden niet impliciet vermenigvuldigd met het aantal processors.

minWorkerThreads

Vanaf ASP.NET 1.0 Service Pack 3 en ASP.NET 1.1 bevat ASP.NET ook de volgende configuratie-instelling die bepaalt hoeveel worker-threads kunnen direct aan een externe aanvraag beschikbaar worden gesteld.
<processModel minWorkerThreads="1">
Threads die worden beheerd door deze instelling kunnen worden gemaakt op een veel hogere snelheid dan worker-threads die zijn gemaakt op basis van de CLR van standaard "thread-tuning"-mogelijkheden. Deze instelling biedt ASP.NET op service-aanvragen die plotseling volloopt de aanvraagwachtrij ASP.NET gelegenheid een back-end-server, een plotselinge burst verzoeken van het clienteinde, of iets dergelijks die leiden een plotselinge toename van het aantal aanvragen in de wachtrij tot zou. De standaardwaarde voor de parameter minWorkerThreads is 1. Het is raadzaam dat u de waarde voor de parameter minWorkerThreads ingesteld op de volgende waarde.
minWorkerThreads = maxWorkerThreads / 2
De parameter minWorkerThreads is standaard niet aanwezig in het bestand Web.config of Machine.config-bestand. Deze instelling wordt impliciet vermenigvuldigd met het aantal processors.

maxconnection

De parameter maxconnection bepaalt u hoeveel verbindingen kunnen worden gemaakt met een specifiek IP-adres. De parameter wordt als volgt weergegeven:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Als de code van de toepassing wordt verwezen naar de toepassing door de hostnaam in plaats van IP-adres, moet de parameter als volgt uitzien:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://hostname" maxconnection="12">
</connectionManagement>
Ten slotte, als de toepassing wordt gehost op een andere poort dan 80, heeft de parameter op te nemen van de niet-standaard poort in de URI, zoals de volgende:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
De instellingen voor de parameters die eerder in dit artikel worden besproken, zijn alle op het procesniveau van het. De instelling van de parameter maxconnection echter van toepassing op AppDomain-niveau. Standaard, omdat deze instelling is van toepassing op AppDomain-niveau kunt u maximaal twee verbindingen met een specifiek IP-adres vanuit elk AppDomain in uw proces.

executionTimeout

ASP.NET gebruikt de volgende configuratie-instelling voor het beperken van de uitvoertijd van aanvraag:
<httpRuntime executionTimeout="90"/>
U kunt deze limiet ook instellen met behulp van de eigenschap Server.ScriptTimeout .

Opmerking Als u de waarde van de parameter executionTimeout verhoogt, kunt u wellicht ook de instelling van de parameter processModel responseDeadlockInterval wijzigen.

Aanbevelingen

De instellingen die worden aanbevolen in deze sectie werkt mogelijk niet voor alle toepassingen. Echter kunt de volgende aanvullende informatie u de juiste aanpassingen vaststellen.

Als u een webservice wordt opgeroepen aan één IP-adres van elke ASPX-pagina, adviseert Microsoft de volgende configuratie-instellingen te gebruiken:
  • De waarden van de parameters maxWorkerThreads en maxIoThreads ingesteld op 100.
  • Stel de waarde van de parameter maxconnection 12 *N (waarbij N staat voor het aantal CPU's die u hebt).
  • Stel de waarden van de parameter minFreeThreads 88 *N en de parameter minLocalRequestFreeThreads 76 *N.
  • De waarde van minWorkerThreads ingesteld op 50. Vergeet niet minWorkerThreads is niet in het configuratiebestand standaard. U moet deze toevoegen.
Enkele van deze aanbevelingen wordt een eenvoudige formule waarbij het aantal processoren op een server. De variabele die het aantal processors in de formules weergeeft is N. Voor deze instellingen, als hyperthreading is ingeschakeld, moet u het aantal logische processors in plaats van het aantal fysieke processors. Bijvoorbeeld als u een server met vier processors met hyperthreading is ingeschakeld, zullen moet de waarde van N in de formules zijn 8 in plaats van 4.

Opmerking Wanneer u deze configuratie gebruikt, kunt u maximaal 12 ASP.NET-aanvragen per processor gelijktijdig uitvoeren omdat 100-88 = 12. Dus ten minste 88 *N worker-threads en 88 *N poort-threads beschikbaar zijn voor andere doeleinden (bijvoorbeeld voor de callbacks van webservices).

U hebt bijvoorbeeld een server met vier processors en dat hyperthreading is ingeschakeld. Op basis van deze formules, zou u de volgende waarden gebruiken voor de configuratie-instellingen die in dit artikel worden vermeld.
<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>

Ook zijn 12 verbindingen per IP-adres voor elk AppDomain per processor beschikbaar wanneer u deze configuratie hebt gebruikt. Dus in het volgende scenario erg weinig conflicten op tussen aanvragen die wachten op verbindingen en de ThreadPool is niet uitgeput:
  • Slechts één toepassing (AppDomain) fungeert als host voor het web.
  • Elke aanvraag voor een ASPX-pagina kunt u één webservice-aanvraag.
  • Alle aanvragen verlopen via hetzelfde IP-adres.
Echter wanneer u deze configuratie gebruikt, scenario's die betrekking hebben op een van de volgende zal waarschijnlijk te veel verbindingen gebruiken:
  • Aanvragen worden naar meerdere IP-adressen.
  • Aanvragen worden omgeleid (statuscode 302).
  • Aanvragen vereisen verificatie.
  • Aanvragen zijn afkomstig uit verschillende AppDomains.
In deze situaties is het raadzaam een lagere waarde voor de parameter maxconnection en hogere waarden voor de parameters minFreeThreads en minLocalRequestFreeThreads gebruiken.

Status

Dit gedrag is inherent aan het ontwerp.

Meer informatie

Als er slechte prestaties en bronconflicten op IIS 7.0 met ASP.NET, gaat u naar de volgende Microsoft-blogs:

Referenties

Ga naar de volgende website van Microsoft Developer Network (MSDN) voor meer informatie:
Eigenschappen

Artikel-id: 821268 - Laatst bijgewerkt: 14 feb. 2017 - Revisie: 2

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

Feedback