Conflicten, slechte prestaties en impasses wanneer u webserviceverzoeken uitvoert vanuit ASP.NET-toepassingen

Vertaalde artikelen Vertaalde artikelen
Artikel ID: 821268 - Bekijk de producten waarop dit artikel van toepassing is.
Alles uitklappen | Alles samenvouwen

Op deze pagina

Symptomen

Wanneer u vanuit een ASP.NET-toepassing aanroepen verstuurt naar XML-webservices, treden er problemen op door conflicten, slechte prestaties en impasses. Clients ervaren dit als verzoeken die niet worden uitgevoerd of die erg veel tijd in beslag nemen. Als er sprake is van een impasse, kan het werkproces worden verwijderd. De volgende berichten kunnen worden vastgelegd in het logboek voor toepassingsgebeurtenissen.
  • Als u Microsoft Internet Information Services (IIS) 5.0 gebruikt, worden de volgende berichten toegevoegd aan het logboek voor toepassingsgebeurtenissen:

    Type:     Fout
       Bron:   ASP.NET 1.0.3705.0
       Categorie: Geen
       Gebeurtenis-id:       1003
       Datum:           5/4/2003
       Tijd:           6:18:23 PM
       Gebruiker:           n.v.t.
       Computer:       <ComputerName>
       Beschrijving:
          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.

  • Als u IIS 6.0 gebruikt, worden de volgende berichten toegevoegd aan het logboek voor toepassingsgebeurtenissen:

    Type:     Warning
       Bron:   W3SVC-WP
       Categorie: Geen
       Gebeurtenis-id:       2262
       Datum:           5/4/2003
       Tijd:           1:02:33 PM
       Gebruiker:           n.v.t.
       Computer:       <computernaam>
       Beschrijving:
          ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' is als beschadigd gemeld
          om de volgende reden: 'Impasse gedetecteerd'.

  • Als u IIS 6.0 gebruikt, worden de volgende berichten toegevoegd aan het systeemlogboek:

    Type:     Warning
       Bron:   W3SVC
       Categorie: Geen
       Gebeurtenis-id:       1013
       Datum:           5/4/2003
       Tijd:           1:03:47 PM
       Gebruiker:           n.v.t.
       Computer:       <computernaam>
       Beschrijving:
          Een proces voor groep van toepassingen DefaultAppPool heeft tijdens het afsluiten de tijdlimiet overschreden.
          De proces-id is <xxxx>.

Bovendien kan het volgende foutbericht voor een uitzondering worden weergegeven wanneer u de methode HttpWebRequest.GetResponse aanroept:
?System.InvalidOperationException: There were not enough free threads in the ThreadPool object to complete the operation.?
Mogelijk wordt ook het volgende uitzonderingsbericht weergegeven in de browser:
?HttpException (0x80004005): Time-out bij opdracht.?
Opmerking Dit artikel geldt ook voor toepassingen die HttpWebRequest rechtstreeks aanroepen.

Oorzaak

Dit probleem treedt op omdat ASP.NET beperkingen hanteert voor het aantal worker-threads en poort-threads dat in een aanroep is toegestaan voor het uitvoeren van aanvragen.

Een aanroep van een webservice gebruikt meestal één worker-thread voor het uitvoeren van de code voor het verzenden van de aanvraag en één poort-thread voor het ontvangen van de callback van de webservice. Als de aanvraag echter wordt doorgestuurd of verificatie vereist, heeft de aanroep mogelijk twee worker-threads en twee poort-threads nodig. Als er nu tegelijkertijd verschillende aanroepen naar een webservice worden verzonden, kan dit tot gevolg hebben dat er geen threads meer beschikbaar zijn in de ThreadPool.

Stel dat de ThreadPool is ingesteld op maximaal 10 worker-threads en dat alle 10 de threads worden gebruikt voor het uitvoeren van code die wacht op uitvoering van een callback. De callback kan dan nooit plaatsvinden omdat alle werkitems die in de wachtrij van de ThreadPool worden gezet, 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 te beperken. Over het algemeen werkt deze parameter zoals verwacht. Als op hetzelfde moment echter diverse toepassingen aanvragen verzenden naar een bepaald IP-adres, moeten threads wellicht wachten op een beschikbare verbinding.

Oplossing

U kunt deze problemen oplossen door de volgende parameters in het bestand Machine.config aan te passen:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
Ga als volgt te werk om deze problemen op te lossen:
  • Beperk het aantal ASP.NET-aanvragen dat tegelijkertijd kan worden uitgevoerd tot ongeveer 12 per processor.
  • Stel voor webservice-callbacks geen beperkingen in voor het gebruik van threads in de ThreadPool.
  • Selecteer een geschikte waarde voor de parameter maxconnections. Belangrijke aspecten hierbij zijn het aantal IP-adressen en AppDomains dat wordt gebruikt.
Opmerking De aanbeveling om het aantal ASP.NET-aanvragen te beperken tot 12 per processor is niet voor alle situaties de juiste oplossing. In de praktijk is echter gebleken dat dit aantal voor de meeste toepassingen prima werkt.

maxWorkerThreads en maxIoThreads

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

minFreeThreads en minLocalRequestFreeThreads

ASP.NET bevat daarnaast de volgende configuratie-instellingen die bepalen hoeveel worker-threads en poort-threads er beschikbaar moeten zijn om een externe of lokale aanvraag te starten:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
. Als er onvoldoende threads beschikbaar zijn, wordt de aanvraag in de wachtrij gezet totdat er voldoende threads vrij zijn voor de aanvraag. Dit betekent dat ASP.NET op hetzelfde moment nooit meer dan het volgende aantal aanvragen zal uitvoeren:
(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 voor het bepalen van het aantal worker-threads dat direct beschikbaar kan worden gesteld voor het afhandelen van een externe aanvraag.
<processModel minWorkerThreads="1">
Threads die met deze instelling worden aangestuurd, kunnen veel sneller beschikbaar worden gesteld dan worker-threads die beschikbaar komen op basis van de standaardfuncties voor het afregelen van threads van CLR. Deze instelling biedt ASP.NET de gelegenheid aanvragen ook af te handelen wanneer de wachtrij van ASP.NET plotseling volloopt. Mogelijke oorzaken hiervoor zijn vertragingen op een backend-server, een grote hoeveelheid gelijktijdige aanvragen van clients of een vergelijkbare situatie die tot gevolg heeft dat het aantal aanvragen in de wachtrij ineens sterk toeneemt. De standaardwaarde voor de parameter minWorkerThreads is 1. Het is raadzaam de waarde voor de parameter minWorkerThreads in te stellen op de volgende waarde:
minWorkerThreads = maxWorkerThreads / 2
. De parameter minWorkerThreads is standaard niet opgenomen in het bestand Web.config of Machine.config. Deze instelling wordt impliciet vermenigvuldigd met het aantal processors.

maxconnection

De parameter maxconnection bepaalt het aantal verbindingen dat met een specifiek IP-adres tot stand kan worden gebracht. De parameter heeft de volgende notatie:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="65.53.32.230" maxconnection="12">
</connectionManagement>
De instellingen voor de eerder besproken parameters gelden per proces. De parameter maxconnection wordt echter ingesteld op AppDomain-niveau. Om die reden kunnen er vanuit elk AppDomain in een proces standaard maximaal twee verbindingen worden opgezet met een bepaald IP-adres.

executionTimeout

ASP.NET gebruikt de volgende configuratie-instelling om de uitvoeringstijd van een aanvraag te beperken:
<httpRuntime executionTimeout="90"/>
. U kunt deze limiet ook instellen via de eigenschap Server.ScriptTimeout.

Opmerking Als u een hogere waarde opgeeft voor de parameter executionTimeout, moet u wellicht ook de instelling van de parameter processModel responseDeadlockInterval wijzigen.

Aanbevelingen

De instellingen die worden aanbevolen in deze sectie zijn mogelijk niet geschikt voor alle toepassingen. Aan de hand van de onderstaande extra informatie kunt u echter wel de juiste aanpassingen vaststellen.

Als een webservice vanaf elke ASPX-pagina één aanroep verstuurt naar een specifiek IP-adres, adviseert Microsoft de volgende configuratie-instellingen:
  • Stel de waarden van de parameters maxWorkerThreads en maxIoThreads in op 100.
  • Stel de waarde van de parameter maxconnection in op 12*N (waarbij u N vervangt door het aantal processors).
  • Stel de waarde van de parameter minFreeThreads in op 88*N en van minLocalRequestFreeThreads op76*N.
  • Stel de waarde van minWorkerThreads in op 50. Zoals eerder aangegeven, maakt minWorkerThreads standaard geen deel uit van het configuratiebestand. U moet de parameter zelf toevoegen.
In enkele van deze aanbevelingen wordt een eenvoudige formule gehanteerd met betrekking tot het aantal processors in een server. De variabele N stelt het aantal processors voor in de formules. Als in uw omgeving hyperthreading is ingeschakeld, moet u in deze formules het aantal logische processors gebruiken en niet het aantal fysieke processors. Als u bijvoorbeeld een server met vier processors hebt waarop hyperthreading is ingeschakeld, is de waarde van N in de formules 8 en niet 4.

Opmerking Wanneer u deze configuratie gebruikt, kunt u tegelijkertijd maximaal 12 ASP.NET-aanvragen per processor aanvragen, aangezien 100-88=12. Er zijn dus ten minste 88*N worker-threads en 88*N poort-threads beschikbaar voor andere doeleinden (zoals voor de callbacks van webservices).

Stel dat u een server hebt met vier processors en dat hyperthreading is ingeschakeld. Op basis van deze formules moet u dan de volgende waarden gebruiken voor de configuratie-instellingen die in dit artikel worden besproken.
<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50">
<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608">
<connectionManagement>
	<add address="[IP-adres]" maxconnection="96"/>
</connectionManagement>

Verder is het zo dat er in deze configuratie voor elk AppDomain per processor 12 verbindingen beschikbaar zijn voor elk IP-adres. In het volgende scenario treden er dan ook erg weinig conflicten op tussen aanvragen die wachten op verbindingen en raakt de ThreadPool nooit uitgeput:
  • De webserver is host voor maar één toepassing (AppDomain).
  • Elke aanvraag voor een ASPX-pagina komt overeen met één webservice-aanvraag.
  • Alle aanvragen verlopen via hetzelfde IP-adres.
Als er in deze configuratie echter scenario's worden gebruikt met een van de volgende voorwaarden, zullen er waarschijnlijk te veel verbindingen worden gebruikt:
  • Aanvragen worden naar verschillende IP-adressen gestuurd.
  • Aanvragen worden omgeleid (statuscode 302).
  • Aanvragen vereisen verificatie.
  • Aanvragen zijn afkomstig uit verschillende AppDomains.
In deze scenario's is het raadzaam een lagere waarde te gebruiken voor de parameter maxconnection en hogere waarden voor de parameters minFreeThreads en minLocalRequestFreeThreads.

Status

Dit gedrag is inherent aan het ontwerp van het product.

Referenties

Ga naar de volgende MSDN-website (Microsoft Developer Network) voor meer informatie:
http://msdn2.microsoft.com/en-us/library/ms998549.aspx

Eigenschappen

Artikel ID: 821268 - Laatste beoordeling: dinsdag 13 maart 2007 - Wijziging: 7.4
De informatie in dit artikel is van toepassing op:
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Trefwoorden: 
kbprb KB821268
Vrijwaring inhoud KB-artikelen over niet langer ondersteunde producten
Dit artikel heeft betrekking op producten waarvoor Microsoft geen ondersteuning meer biedt. Daarom wordt dit artikel alleen in de huidige vorm aangeboden en wordt het niet meer bijgewerkt.

Geef ons 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