Konflikte, Leistungseinbußen und Deadlocks, wenn Sie Webdienste aus einer ASP.NET Anwendung aufrufen

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 821268 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Problembeschreibung

Wenn Sie Webdienste aus einer Microsoft ASP.NET Anwendung aufrufen, können Sie Konflikte, Leistungseinbußen und Deadlocks auftreten. Clients melden eventuell, dass Anforderungen mehr reagieren (oder "hängen") oder sehr lange dauern ausführen. Wenn ein Deadlock vermutet wird, kann der Arbeitsprozess wiederverwendet werden. Sie können die folgenden Meldungen im Ereignisprotokoll Anwendung angezeigt.
  • Wenn Sie Internet Information Services (IIS) 5.0 verwenden, erhalten Sie die folgenden Meldungen im Anwendungsprotokoll protokolliert:

       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.

  • Wenn Sie IIS 6.0 verwenden, erhalten Sie die folgenden Meldungen im Anwendungsprotokoll protokolliert:

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

  • Wenn Sie IIS 6.0 verwenden, erhalten Sie die folgenden Meldungen im Systemprotokoll:

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

Sie können auch folgende Fehlermeldung Ausnahme Meldung an, wenn Sie stellen einen Aufruf der Methode HttpWebRequest.GetResponse :
"System.InvalidOperationException: Es sind nicht genügend freie Threads im ThreadPool-Objekt zum Abschließen der der Vorgang."
Sie können auch die folgende Ausnahmefehlermeldung erhalten. im Browser:
"HttpException (0 x 80004005): Request timed Out."
Hinweis Dieser Artikel gilt auch für Anwendungen, die HttpWebRequest -Anforderungen direkt vornehmen.

Ursache

Dieses Problem kann auftreten, weil ASP.NET die Anzahl begrenzt der Worker-Threads und Komplettierungsportthreads, mit denen ein Aufruf ausführen Anforderungen.

In der Regel verwendet ein Aufruf an einen Webdienst einen Arbeits-Thread zum Ausführen des Codes, der die Anforderung sendet und ein Komplettierungsportthread den Rückruf vom Webdienst empfangen. Wenn allerdings die Anforderung umgeleitet wird oder eine Authentifizierung benötigt, kann der Aufruf bis zu zwei Arbeitsthreads und zwei Completion-Port-Threads verwenden. Aus diesem Grund können Sie den verwalteten ThreadPool aufbrauchen, wenn mehrere Webdienstaufrufe gleichzeitig auftreten.

Genommen Sie an, dass der ThreadPool auf 10 Arbeitsthreads beschränkt ist und dass alle 10 Arbeitsthreads gerade Code ausführen, die auf einen Rückruf zur Ausführung wartet. Der Rückruf kann nie ausgeführt, da alle Arbeitsaufgaben, die an den ThreadPool angereiht sind blockiert sind, bis ein Thread verfügbar wird.

Eine andere ist mögliche Konfliktquelle Maxconnection -Parameters, der System.Net -Namespace verwendet, um die Anzahl der Verbindungen beschränken. Im Allgemeinen Diese Grenze funktioniert wie erwartet. Jedoch Wenn viele Anwendungen versuchen, viele machen Anforderungen an eine einzige IP-Adresse zur gleichen Zeit Threads eventuell warten eine verfügbare Verbindung.

Lösung

Um diese Probleme zu beheben, können Sie die folgenden Parameter in der Datei Machine.config auf Ihre Situation anpassen optimieren:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxConnection
  • "executionTimeout"
Um diese Probleme erfolgreich zu beheben, müssen durchführen Sie die folgenden Aktionen:
  • Die Anzahl der ASP.NET Anforderungen, die ausgeführt werden können gleichzeitig auf 12 pro CPU.
  • Lassen Sie Webdienst-Rückrufe Threads im ThreadPool frei zu verwenden.
  • Wählen Sie einen geeigneten Wert für den Parameter Maxconnections . Treffen Sie Ihre Auswahl auf die Anzahl der IP-Adressen und Anwendungsdomänen, die verwendet werden.
Hinweis Die Empfehlung, begrenzen die Anzahl der ASP.NET Anforderungen auf 12 pro CPU ist eher willkürlich. Allerdings erwies sich dieses Limit auch für die Arbeit die meisten Anwendungen.

MaxWorkerThreads und maxIoThreads

ASP.NET verwendet die folgenden beiden Konfigurationseinstellungen Begrenzen Sie die maximale Anzahl von Arbeitsthreads und Abschlussthreads, die verwendet:
<processModel maxWorkerThreads="20" maxIoThreads="20">
Die Parameter MaxWorkerThreads und maxIoThreads werden implizit mit der Anzahl der CPUs multipliziert. Für Beispielsweise haben Sie zwei Prozessoren ist die maximale Anzahl von Worker-threads die folgenden:
2 * MaxWorkerThreads

MinFreeThreads und minLocalRequestFreeThreads

ASP.NET enthält außerdem die folgende Konfiguration Einstellungen, die bestimmen, wie viele Arbeitsthreads und Abschluss-Threads Port muss eine Remoteanfrage oder eine lokale Anforderung starten verfügbar sein:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Wenn nicht genügend Threads verfügbar sind, wird die Anfrage zurückgestellt. bis genügend Threads frei, die Anforderung zu machen sind. Aus diesem Grund wird ASP.NET nicht mehr als die folgende Anzahl von Anforderungen zur gleichen Zeit ausführen:
(MaxWorkerThreads*Anzahl der CPUs)-MinFreeThreads
Hinweis Der Parameter MinFreeThreads und der Parameter minLocalRequestFreeThreads werden nicht implizit mit der Anzahl der CPUs multipliziert.

minWorkerThreads

Seit ASP.NET 1.0 Servicepack 3 und ASP.NET 1.1 ASP.NET enthält außerdem die folgenden Konfigurationseinstellungen, die bestimmt, wie viele Worker-Threads können sofort an einem Remote-Dienst zur Verfügung gestellt werden Anforderung.
<processModel minWorkerThreads="1">
Threads hängen von dieser Einstellung kann sehr viel schneller als erstellt werden Worker-Threads, die von der CLR Standard "Thread-Optimierung" erstellt werden Funktionen. Diese Einstellung ermöglicht ASP.NET auf Serviceanforderungen, die möglicherweise plötzlich Füllen der Warteschlange der ASP.NET aufgrund einer Verlangsamung auf einem Back-end Ein plötzlicher Ausbruch der Anforderungen von der Clientseite oder etwas Ähnliches-Server Das würde einen plötzlichen Anstieg der Anzahl der Anforderungen in der Warteschlange. Die Standardwert für den Parameter MinWorkerThreads ist 1. Es wird empfohlen, dass Sie den Wert für den Parameter MinWorkerThreads auf den folgenden Wert festlegen.
minWorkerThreads = maxWorkerThreads / 2
Der Parameter MinWorkerThreads wird standardmäßig nicht in der Datei Web.config vorhanden oder die Datei "Machine.config". Diese Einstellung wird die Anzahl der implizit multipliziert. CPUs.

maxConnection

Der Parameter Maxconnection bestimmt, wie viele Verbindungen hergestellt werden können, zu einem bestimmte IP-Adresse. Der Parameter wird wie folgt angezeigt:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Wenn die Anwendung Code die Anwendung durch Hostnamen statt IP-Adresse verweist, sollten der Parameter wie folgt aussehen:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
Wenn die Anwendung auf einen anderen Port als 80 gehostet wird, muss der Parameter schließlich den nicht standardmäßigen Port in der URI, ähnlich der folgenden enthalten:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
Die Einstellungen für die Parameter, die weiter oben in diesem Artikel beschriebenen sind alle auf der Prozessebene. Allerdings gilt die Parameter Maxconnection -Einstellung für die AppDomain-Ebene. In der Standardeinstellung Da diese Einstellung auf der AppDomain-Ebene angewendet wird, können Sie bis zu erstellen. zwei Verbindungen auf eine bestimmte IP-Adresse von jeder AppDomain in Ihrem Prozess.

"executionTimeout"

ASP.NET verwendet die folgenden Konfigurationseinstellungen Beschränken Sie die Ausführungszeit der Anforderung:
<httpRuntime executionTimeout="90"/>
Sie können dieses Limit auch mithilfe der Eigenschaft Server.ScriptTimeout festlegen.

Hinweis Wenn Sie den Wert des Parameters ExecutionTimeout erhöhen, müssen Sie auch die ProcessModel Ändern ResponseDeadlockInterval Parametereinstellung.

Empfehlungen

Die Einstellungen, die in diesem Abschnitt empfohlenen funktioniert möglicherweise nicht für alle Anwendungen. Allerdings kann die folgende zusätzliche Informationen Sie helfen Nehmen Sie die entsprechenden Änderungen vor.

If machen Sie einen Webdienstaufruf zu einer einzigen IP-Adresse von jeder ASPX-Seite, Microsoft empfiehlt, dass Sie die folgenden Konfigurationseinstellungen verwenden:
  • Die Werte der Parameter MaxWorkerThreads und maxIoThreads auf 100festgelegt.
  • Legen Sie den Wert für den Parameter Maxconnection auf 12 *N (wo N ist die Anzahl der CPUs, Sie haben).
  • Legen Sie die Werte der Parameter MinFreeThreads auf 88 *N und der Parameter minLocalRequestFreeThreads76 *N.
  • Legen Sie der Wert der MinWorkerThreads auf 50. Denken Sie daran, MinWorkerThreads nicht in der Konfigurationsdatei in der Standardeinstellung. Sie müssen es hinzufügen.
Einige dieser Empfehlungen nHalten Sie eine einfache Formel bei, die die Anzahl beinhaltet der CPUs auf einem Server. Die Variable, die die Anzahl der CPUs in der Formeln N. Für diese Einstellungen, wenn Sie Hyperthreading aktiviert haben, Sie müssen die Anzahl der logischen CPUs anstelle der Anzahl der physischen CPUs verwenden. Wenn Sie einen Server mit vier Prozessoren mit Hyperthreading aktiviert ist, dann haben z. B. der Wert der N in den Formeln werden 8 statt 4.

Hinweis Wenn Sie diese Konfiguration verwenden, können Sie maximal 12 ausführen. ASP.NET pro CPU gleichzeitig angefordert, da 100-88 = 12. Aus diesem Grund mindestens 88 *N Arbeitskraft Threads und 88 *N Komplettierungsportthreads sind für andere verfügbar wird (z. B. für Webdienst-Rückrufe) verwendet.

Angenommen, Sie verfügen über einen Server mit vier Prozessoren mit Hyper-Threading aktiviert. Basierend auf diesen Formeln, verwenden Sie die folgenden Werte für die Konfigurationseinstellungen, die in diesem Artikel erwähnt werden.
<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>

Auch wenn Sie diese Konfiguration verwenden, stehen 12 Verbindungen pro-CPU pro IP-Adresse für jede Anwendungsdomäne. Aus diesem Grund in der folgenden Szenario tritt sehr geringe Konflikte auf, wenn Anforderungen warten Verbindungen und der ThreadPool ist nicht erschöpft:
  • Das Netz enthält nur eine Anwendung (AppDomain).
  • Jede Anforderung für eine ASPX-Seite wird eine Webdienstanforderung.
  • Alle Anfragen werden an die IP-Adresse.
Jedoch, wenn Sie diese Konfiguration verwenden, beinhalten Szenarien eine der folgenden werden wahrscheinlich zu viele Verbindungen verwenden:
  • Anfragen werden an mehrere IP-Adressen.
  • Anfragen werden umgeleitet (302 Statuscode).
  • Anfragen erfordern eine Authentifizierung.
  • Anforderungen werden von mehreren AppDomains gestellt.
In diesen Szenarien ist es eine gute Idee, verwenden Sie einen niedrigeren Wert für der Parameter Maxconnection und höhere Werte für den Parameter MinFreeThreads und MinLocalRequestFreeThreads .

Status

Dies Verhalten ist beabsichtigt.

Weitere Informationen

Wenn eine schlechte Leistung und Konflikte für IIS 7.0, zusammen mit ASP.NET auftreten, fahren Sie mit der folgenden Microsoft-Blogs:
ASP.NET Thread Usage on IIS 7.5, IIS 7.0 und IIS 6.0

ASP.net hängt in IIS 7.0

Informationsquellen

Weitere Informationen finden Sie in der folgenden Microsoft Developer Network (MSDN)-Website:
Verbessern der Leistung von ASP.NET

Eigenschaften

Artikel-ID: 821268 - Geändert am: Mittwoch, 6. Februar 2013 - Version: 1.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Keywords: 
kbprb kbmt KB821268 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 821268
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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