Sie sind zurzeit offline. Es wird auf die erneute Herstellung einer Internetverbindung gewartet.

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

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
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:
Informationsquellen
Weitere Informationen finden Sie in der folgenden Microsoft Developer Network (MSDN)-Website:

Warnung: Dieser Artikel wurde automatisch übersetzt.

Eigenschaften

Artikelnummer: 821268 – Letzte Überarbeitung: 02/06/2013 00:44:00 – Revision: 1.0

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

  • kbprb kbmt KB821268 KbMtde
Feedback
> rc="https://c1.microsoft.com/c.gif?DI=4050&did=1&t=">=">l>/html>html>