Verwenden asynchroner Methoden in ASP.NET 4.5

von Rick Anderson

In diesem Lernprogramm lernen Sie die Grundlagen der Erstellung einer asynchronen ASP.NET Webanwendung mit Visual Studio Express 2012 für Web kennen, die eine kostenlose Version von Microsoft Visual Studio ist. Sie können auch Visual Studio 2012 verwenden. Die folgenden Abschnitte sind in diesem Lernprogramm enthalten.

• Verarbeiten von Anforderungen durch den Threadpool
• Auswählen synchroner oder asynchroner Methoden
• Die Beispielanwendung
• Die Synchronseite von Gizmos
• Erstellen einer asynchronen Gizmos-Seite
• Ausführen mehrerer Vorgänge parallel
• Verwenden eines Abbruchtokens
• Serverkonfiguration für Webdienstaufrufe mit hoher Parallelität/hoher Latenz

Für dieses Tutorial finden Sie ein vollständiges Beispiel in
https://github.com/RickAndMSFT/Async-ASP.NET/ auf der GitHub-Website .

ASP.NET 4.5 Web Pages in Kombination mit .NET 4.5 ermöglichen es Ihnen, asynchrone Methoden zu registrieren, die ein Objekt vom Typ Task zurückgeben. .NET Framework 4 hat ein asynchrones Programmierkonzept eingeführt, das als Aufgabe bezeichnet wird und ASP.NET 4.5 Task unterstützt. Aufgaben werden durch den Aufgabentyp und verwandte Typen im Namespace "System.Threading.Tasks " dargestellt. .NET Framework 4.5 baut auf dieser asynchronen Unterstützung mit den await - und asynchronen Schlüsselwörtern auf, die das Arbeiten mit Task-Objekten wesentlich weniger komplex machen als vorherige asynchrone Ansätze. Das Await-Schlüsselwort ist syntaktische Kurzform, um anzugeben, dass ein Codeabschnitt asynchron auf einen anderen Codeabschnitt warten soll. Das asynchrone Schlüsselwort stellt einen Hinweis dar, mit dem Sie Methoden als aufgabenbasierte asynchrone Methoden markieren können. Die Kombination aus Await, async und dem Task-Objekt erleichtert es Ihnen, asynchronen Code in .NET 4.5 zu schreiben. Das neue Modell für asynchrone Methoden wird als aufgabenbasiertes asynchrones Muster (TAP) bezeichnet. In diesem Lernprogramm wird davon ausgegangen, dass Sie mit der asynchronen Programmierung mit await - und asynchronen Schlüsselwörtern und dem Task-Namespace vertraut sind.

Weitere Informationen zur Verwendung von Await - und asynchronen Schlüsselwörtern und dem Task-Namespace finden Sie in den folgenden Verweisen.

• Whitepaper: Asynchronie in .NET
• Häufig gestellte Fragen zu Async/Await
• Asynchrone Programmierung in Visual Studio

Wie Anforderungen vom Threadpool verarbeitet werden

Auf dem Webserver verwaltet das .NET Framework einen Pool von Threads, die für die Bearbeitung von ASP.NET-Anforderungen verwendet werden. Wenn eine Anforderung eingeht, wird ein Thread aus dem Pool zugewiesen, um diese Anforderung zu verarbeiten. Wenn die Anforderung synchron verarbeitet wird, ist der Thread, der die Anforderung verarbeitet, ausgelastet, während die Anforderung verarbeitet wird, und dieser Thread kann keine andere Anforderung verarbeiten.

Dies ist möglicherweise kein Problem, da der Thread-Pool groß genug ist, um viele beschäftigte Threads aufzunehmen. Die Anzahl der Threads im Threadpool ist jedoch begrenzt (der Standardwert für .NET 4.5 ist 5.000). In großen Anwendungen mit hoher Gleichzeitigkeit lang laufender Anforderungen sind möglicherweise alle verfügbaren Threads ausgelastet. Diese Bedingung wird als Threadhunger bezeichnet. Wenn diese Bedingung erreicht ist, werden anforderungen vom Webserver in die Warteschlange gestellt. Wenn die Anforderungswarteschlange voll ist, lehnt der Webserver Anforderungen mit einem HTTP 503-Status ab (Server zu ausgelastet). Der CLR-Threadpool hat Einschränkungen für neue Threadeinfügungen. Wenn die Parallelität platzt (d. h. Ihre Website kann plötzlich eine große Anzahl von Anforderungen abrufen) und alle verfügbaren Anforderungsthreads aufgrund von Back-End-Aufrufen mit hoher Latenz ausgelastet sind, kann die eingeschränkte Threadeinfügungsrate dazu führen, dass Ihre Anwendung sehr schlecht reagiert. Darüber hinaus hat jeder neue Thread, der dem Threadpool hinzugefügt wird, Mehraufwand (z. B. 1 MB Stapelspeicher). Eine Webanwendung, die synchrone Methoden verwendet, um Aufrufe mit hoher Latenz zu verarbeiten, bei denen der Threadpool auf das .NET 4.5-Standard-Maximum von 5. 000 Threads wächst, verbraucht etwa 5 GB mehr Arbeitsspeicher als eine Anwendung, die den Dienst mit asynchronen Methoden und nur 50 Threads unterstützt. Wenn Sie asynchron arbeiten, verwenden Sie nicht immer einen Thread. Wenn Sie beispielsweise eine asynchrone Webdienstanforderung vornehmen, verwendet ASP.NET keine Threads zwischen dem asynchronen Methodenaufruf und dem Await. Die Verwendung des Threadpools für Dienstanforderungen mit hoher Latenz kann zu einem großen Speicherbedarf und einer schlechten Auslastung der Serverhardware führen.

Verarbeiten asynchroner Anforderungen

In Webanwendungen, die eine große Anzahl gleichzeitiger Anforderungen beim Start sehen oder eine platzende Last aufweisen (wobei die Parallelität plötzlich zunimmt), erhöht das asynchrone Ausführen von Webdienstaufrufen die Reaktionsfähigkeit Ihrer Anwendung. Eine asynchrone Anforderung benötigt dieselbe Zeit wie eine synchrone Anforderung. Wenn beispielsweise eine Anforderung einen Webdienstaufruf ausführt, der zwei Sekunden erfordert, dauert die Anforderung zwei Sekunden, unabhängig davon, ob sie synchron oder asynchron ausgeführt wird. Während eines asynchronen Aufrufs wird ein Thread jedoch nicht daran gehindert, auf andere Anforderungen zu reagieren, während er auf den Abschluss der ersten Anforderung wartet. Daher verhindern asynchrone Anforderungen die Anhäufung von Anfragen in der Warteschlange und das Wachstum des Threadpools, wenn viele gleichzeitige Anforderungen vorhanden sind, die lang andauernde Vorgänge aufrufen.

Auswählen synchroner oder asynchroner Methoden

In diesem Abschnitt werden Richtlinien für die Verwendung synchroner oder asynchroner Methoden aufgeführt. Dies sind nur Richtlinien; Überprüfen Sie jede Anwendung einzeln, um festzustellen, ob asynchrone Methoden bei der Leistung helfen.

Verwenden Sie im Allgemeinen synchrone Methoden für die folgenden Bedingungen:

• Die Operationen sind einfach oder kurzzeitig.
• Einfachheit ist wichtiger als Effizienz.
• Die Vorgänge sind in erster Linie CPU-Vorgänge anstelle von Vorgängen, die einen umfangreichen Datenträger- oder Netzwerkaufwand erfordern. Die Verwendung asynchroner Methoden für CPU-gebundene Vorgänge bietet keine Vorteile und führt zu mehr Aufwand.

Verwenden Sie im Allgemeinen asynchrone Methoden für die folgenden Bedingungen:

• Sie rufen Dienste auf, die über asynchrone Methoden genutzt werden können, und Sie verwenden .NET 4.5 oder höher.

• Die Vorgänge sind netzwerkgebunden oder I/O-gebunden, anstatt CPU-gebunden.

• Parallelität ist wichtiger als die Einfachheit des Codes.

• Sie möchten einen Mechanismus bereitstellen, mit dem Benutzer eine lange ausgeführte Anforderung abbrechen können.

• Wenn der Vorteil des Wechselns von Threads die Kosten des Kontextwechsels überwiegt. Im Allgemeinen sollten Sie eine Methode asynchron machen, wenn die synchrone Methode den ASP.NET Anforderungsthread blockiert, während keine Arbeit ausgeführt wird. Durch die asynchrone Ausführung des Aufrufs wird der ASP.NET-Anforderungsthread nicht blockiert und arbeitet nicht, während er auf den Abschluss der Webdienstanforderung wartet.

• Tests zeigen, dass die Blockierungsvorgänge ein Engpass bei der Websiteleistung sind und IIS weitere Anforderungen mithilfe asynchroner Methoden für diese blockierenden Aufrufe verarbeiten kann.

  Das herunterladbare Beispiel zeigt, wie asynchrone Methoden effektiv verwendet werden. Das bereitgestellte Beispiel wurde entwickelt, um eine einfache Demonstration der asynchronen Programmierung in ASP.NET 4.5 bereitzustellen. Das Beispiel ist keine Referenzarchitektur für die asynchrone Programmierung in ASP.NET. Das Beispielprogramm ruft ASP.NET Web-API-Methoden auf, die wiederum Task.Delay aufrufen, um lange ausgeführte Webdienstaufrufe zu simulieren. Die meisten Produktionsanwendungen zeigen keine so offensichtlichen Vorteile für die Verwendung asynchroner Methoden.

Für wenige Anwendungen müssen alle Methoden asynchron sein. Häufig bietet das Konvertieren einiger synchroner Methoden in asynchrone Methoden die beste Effizienzsteigerung für die erforderliche Arbeitsmenge.

Die Beispielanwendung

Sie können die Beispielanwendung von https://github.com/RickAndMSFT/Async-ASP.NET der GitHub-Website herunterladen. Das Repository besteht aus drei Projekten:

• WebAppAsync: Das ASP.NET Web Forms-Projekt, das den Web-API-WebAPIpwg-Dienst verwendet. Der großteil des Codes für dieses Lernprogramm stammt aus diesem Projekt.
• WebAPIpgw: Das ASP.NET MVC 4-Web-API-Projekt, das die Products, Gizmos and Widgets Controller implementiert. Es stellt die Daten für das WebAppAsync-Projekt und das Mvc4Async-Projekt bereit.
• Mvc4Async: Das ASP.NET MVC 4-Projekt, das den code enthält, der in einem anderen Lernprogramm verwendet wird. Es führt Web-API-Aufrufe an den WebAPIpwg-Dienst durch.

Die Synchronseite von Gizmos

Der folgende Code zeigt die Page_Load synchrone Methode, die zum Anzeigen einer Liste von Gizmos verwendet wird. (Für diesen Artikel ist ein Gizmo ein fiktives mechanisches Gerät.)

public partial class Gizmos : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        var gizmoService = new GizmoService();
        GizmoGridView.DataSource = gizmoService.GetGizmos();
        GizmoGridView.DataBind();
    }
}

Der folgende Code zeigt die GetGizmos Methode des Gizmo-Diensts.

public class GizmoService
{
    public async Task<List<Gizmo>> GetGizmosAsync(
        // Implementation removed.
       
    public List<Gizmo> GetGizmos()
    {
        var uri = Util.getServiceUri("Gizmos");
        using (WebClient webClient = new WebClient())
        {
            return JsonConvert.DeserializeObject<List<Gizmo>>(
                webClient.DownloadString(uri)
            );
        }
    }
}

Die GizmoService GetGizmos Methode übergibt einen URI an einen ASP.NET Web-API-HTTP-Dienst, der eine Liste von Gizmos-Daten zurückgibt. Das WebAPIpgw-Projekt enthält die Implementierung der Web-API gizmos, widget und product -Controller.
Die folgende Abbildung zeigt die Gizmos-Seite aus dem Beispielprojekt.

Erstellen einer asynchronen Gizmos-Seite

Im Beispiel werden die neuen Schlüsselwörter async und await (verfügbar in .NET 4.5 und Visual Studio 2012) verwendet, damit der Compiler dafür verantwortlich ist, die komplizierten Transformationen durchzuführen, die für die asynchrone Programmierung erforderlich sind. Mit dem Compiler können Sie Code mit den synchronen Steuerungsflusskonstrukten von C# schreiben, und der Compiler wendet automatisch die Transformationen an, die erforderlich sind, um Rückrufe zu verwenden, um das Blockieren von Threads zu vermeiden.

ASP.NET asynchronen Seiten müssen die Page-Direktive enthalten, wobei das Async-Attribut auf "true" festgelegt wird. Der folgende Code zeigt die Page-Direktive mit dem Async Attribut, das auf "true" gesetzt ist, für die GizmosAsync.aspx-Seite.

<%@ Page Async="true"  Language="C#" AutoEventWireup="true" 
    CodeBehind="GizmosAsync.aspx.cs" Inherits="WebAppAsync.GizmosAsync" %>

Der folgende Code zeigt die Gizmos synchrone Page_Load Methode und die GizmosAsync asynchrone Seite. Wenn Ihr Browser das HTML 5-Mark-Element <>unterstützt, werden die Änderungen in GizmosAsync gelber Hervorhebung angezeigt.

protected void Page_Load(object sender, EventArgs e)
{
   var gizmoService = new GizmoService();
   GizmoGridView.DataSource = gizmoService.GetGizmos();
   GizmoGridView.DataBind();
}

Die asynchrone Version:

protected void Page_Load(object sender, EventArgs e)
{
    RegisterAsyncTask(new PageAsyncTask(GetGizmosSvcAsync));
}

private async Task GetGizmosSvcAsync()
{
    var gizmoService = new GizmoService();
    GizmosGridView.DataSource = await gizmoService.GetGizmosAsync();
    GizmosGridView.DataBind();
}

Die folgenden Änderungen wurden angewendet, damit die GizmosAsync Seite asynchron sein kann.

• Die Page-Direktive muss das Async Attribut auf "true" festgelegt haben.
• Die RegisterAsyncTask Methode wird verwendet, um eine asynchrone Aufgabe zu registrieren, die den Code enthält, der asynchron ausgeführt wird.
• Die neue GetGizmosSvcAsync-Methode ist mit dem Schlüsselwort async gekennzeichnet, das dem Compiler angibt, Callbacks für Teile des Methodenrumpfs zu generieren und automatisch ein Task zu erstellen, das zurückgegeben wird.
• "Async" wurde an den asynchronen Methodennamen angefügt. Das Anfügen von "Async" ist nicht erforderlich, ist aber die Konvention beim Schreiben asynchroner Methoden.
• Der Rückgabetyp der neuen GetGizmosSvcAsync Methode lautet Task. Der Rückgabetyp von Task steht für laufende Arbeiten und bietet den Aufrufern der Methode ein Handle, über das auf den Abschluss des asynchronen Vorgangs gewartet werden kann.
• Das Await-Schlüsselwort wurde auf den Webdienstaufruf angewendet.
• Die asynchrone Webdienst-API wurde aufgerufen (GetGizmosAsync).

Innerhalb des GetGizmosSvcAsync Methodentexts wird eine andere asynchrone Methode GetGizmosAsync aufgerufen. GetGizmosAsync gibt sofort ein Task<List<Gizmo>> zurück, das schließlich abgeschlossen sein wird, sobald die Daten verfügbar sind. Da Sie nichts anderes tun möchten, bis Sie die Gizmo-Daten haben, wartet der Code auf die Aufgabe (unter Verwendung des Await-Schlüsselworts). Sie können das Await-Schlüsselwort nur in Methoden verwenden, die mit dem asynchronen Schlüsselwort versehen sind.

Das Await-Schlüsselwort blockiert den Thread nicht, bis die Aufgabe abgeschlossen ist. Er registriert den Rest der Methode als Rückruf für die Aufgabe und gibt sofort zurück. Wenn die erwartete Aufgabe schließlich abgeschlossen ist, wird dieser Rückruf aufgerufen und somit die Ausführung der Methode direkt an der Stelle fortgesetzt, an der sie unterbrochen wurde. Weitere Informationen zur Verwendung der await - und asynchronen Schlüsselwörter und des Task-Namespace finden Sie in den asynchronen Verweisen.

Der folgende Code zeigt die GetGizmos und GetGizmosAsync Methoden.

public List<Gizmo> GetGizmos()
{
    var uri = Util.getServiceUri("Gizmos");
    using (WebClient webClient = new WebClient())
    {
        return JsonConvert.DeserializeObject<List<Gizmo>>(
            webClient.DownloadString(uri)
        );
    }
}

public async Task<List<Gizmo>> GetGizmosAsync()
{
    var uri = Util.getServiceUri("Gizmos");
    using (WebClient webClient = new WebClient())
    {
        return JsonConvert.DeserializeObject<List<Gizmo>>(
            await webClient.DownloadStringTaskAsync(uri)
        );
    }
}

Die asynchronen Änderungen ähneln denen, die oben an der GizmosAsync vorgenommen wurden.

• Die Methodensignatur wurde mit dem async Schlüsselwort annotiert, der Rückgabetyp wurde geändert Task<List<Gizmo>>, und Async wurde an den Methodennamen angefügt.
• Die asynchrone HttpClient-Klasse wird anstelle der synchronen WebClient-Klasse verwendet.
• Das Await-Schlüsselwort wurde auf die asynchrone HttpClientGetAsync-Methode angewendet.

Die folgende Abbildung zeigt die asynchrone Gizmo-Ansicht.

Die Browserpräsentation der Gizmos-Daten ist identisch mit der Ansicht, die vom synchronen Aufruf erstellt wurde. Der einzige Unterschied besteht darin, dass die asynchrone Version bei schweren Lasten leistungsintensiver sein kann.

RegisterAsyncTask Notes

Methoden, mit RegisterAsyncTask denen eine Verbindung besteht, werden unmittelbar nach PreRender ausgeführt.

Wenn Sie asynchrone Void-Seitenereignisse direkt verwenden, wie im folgenden Code gezeigt:

protected async void Page_Load(object sender, EventArgs e) {
    await ...;
    // do work
}

Sie haben keine vollständige Kontrolle mehr darüber, wann Ereignisse ausgeführt werden. Wenn z. B. sowohl eine .aspx- als auch eine .Master-Datei Page_Load-Ereignisse definieren und eines oder beide asynchron sind, kann die Reihenfolge der Ausführung nicht garantiert werden. Die gleiche unbestimmte Reihenfolge für Ereignishandler (wie z. B. async void Button_Click) gilt.

Ausführen mehrerer Vorgänge parallel

Asynchrone Methoden haben einen erheblichen Vorteil gegenüber synchronen Methoden, wenn eine Aktion mehrere unabhängige Vorgänge ausführen muss. In der bereitgestellten Stichprobe zeigt die synchrone Seite PWG.aspx(für Produkte, Widgets und Gizmos) die Ergebnisse von drei Webdienstaufrufen an, um eine Liste von Produkten, Widgets und Gizmos zu erhalten. Das ASP.NET Web-API-Projekt , das diese Dienste bereitstellt, verwendet Task.Delay , um Latenz oder langsame Netzwerkaufrufe zu simulieren. Wenn die Verzögerung auf 500 Millisekunden festgelegt ist, dauert die asynchrone PWGasync.aspx Seite etwas mehr als 500 Millisekunden, während die synchrone PWG Version über 1.500 Millisekunden dauert. Die synchrone PWG.aspx Seite wird im folgenden Code angezeigt.

protected void Page_Load(object sender, EventArgs e)
{
    Stopwatch stopWatch = new Stopwatch();
    stopWatch.Start();

    var widgetService = new WidgetService();
    var prodService = new ProductService();
    var gizmoService = new GizmoService();

    var pwgVM = new ProdGizWidgetVM(
        widgetService.GetWidgets(),
        prodService.GetProducts(),
        gizmoService.GetGizmos()
       );
    WidgetGridView.DataSource = pwgVM.widgetList;
    WidgetGridView.DataBind();
    ProductGridView.DataSource = pwgVM.prodList;
    ProductGridView.DataBind();
    GizmoGridView.DataSource = pwgVM.gizmoList;
    GizmoGridView.DataBind();

    stopWatch.Stop();
    ElapsedTimeLabel.Text = String.Format("Elapsed time: {0}", 
        stopWatch.Elapsed.Milliseconds / 1000.0);
}

Der asynchrone Code-Behind PWGasync wird unten angezeigt.

protected void Page_Load(object sender, EventArgs e)
{
    Stopwatch stopWatch = new Stopwatch();
    stopWatch.Start();
    RegisterAsyncTask(new PageAsyncTask(GetPWGsrvAsync));
    stopWatch.Stop();
    ElapsedTimeLabel.Text = String.Format("Elapsed time: {0}",
        stopWatch.Elapsed.Milliseconds / 1000.0);
}

private async Task GetPWGsrvAsync()
{
    var widgetService = new WidgetService();
    var prodService = new ProductService();
    var gizmoService = new GizmoService();

    var widgetTask = widgetService.GetWidgetsAsync();
    var prodTask = prodService.GetProductsAsync();
    var gizmoTask = gizmoService.GetGizmosAsync();

    await Task.WhenAll(widgetTask, prodTask, gizmoTask);

    var pwgVM = new ProdGizWidgetVM(
       widgetTask.Result,
       prodTask.Result,
       gizmoTask.Result
       );

    WidgetGridView.DataSource = pwgVM.widgetList;
    WidgetGridView.DataBind();
    ProductGridView.DataSource = pwgVM.prodList;
    ProductGridView.DataBind();
    GizmoGridView.DataSource = pwgVM.gizmoList;
    GizmoGridView.DataBind();           
}

Die folgende Abbildung zeigt die von der asynchronen PWGasync.aspx Seite zurückgegebene Ansicht.

Verwendung eines Abbruch-Tokens

Asynchrone Methoden, die ein Task zurückgeben, können abgebrochen werden, d. h., sie akzeptieren einen CancellationToken-Parameter, wenn im AsyncTimeout Attribut der Page-Direktive einer bereitgestellt wird. Der folgende Code zeigt die GizmosCancelAsync.aspx Seite mit einem Timeout von einer Sekunde.

<%@ Page  Async="true"  AsyncTimeout="1" 
    Language="C#" AutoEventWireup="true" 
    CodeBehind="GizmosCancelAsync.aspx.cs" 
    Inherits="WebAppAsync.GizmosCancelAsync" %>

Der folgende Code zeigt die GizmosCancelAsync.aspx.cs Datei.

protected void Page_Load(object sender, EventArgs e)
{
    RegisterAsyncTask(new PageAsyncTask(GetGizmosSvcCancelAsync));
}

private async Task GetGizmosSvcCancelAsync(CancellationToken cancellationToken)
{
    var gizmoService = new GizmoService();
    var gizmoList = await gizmoService.GetGizmosAsync(cancellationToken);
    GizmosGridView.DataSource = gizmoList;
    GizmosGridView.DataBind();
}
private void Page_Error(object sender, EventArgs e)
{
    Exception exc = Server.GetLastError();

    if (exc is TimeoutException)
    {
        // Pass the error on to the Timeout Error page
        Server.Transfer("TimeoutErrorPage.aspx", true);
    }
}

In der bereitgestellten Beispielanwendung ruft die Auswahl des GizmosCancelAsync-Links die GizmosCancelAsync.aspx-Seite auf und zeigt den Abbruch (durch Zeitüberschreitung) des asynchronen Aufrufs. Da sich die Verzögerungszeit innerhalb eines zufälligen Bereichs befindet, müssen Sie die Seite möglicherweise ein paar Mal aktualisieren, um die Timeout-Fehlermeldung zu erhalten.

Serverkonfiguration für Webdienstaufrufe mit hoher Parallelität/hoher Latenz

Um die Vorteile einer asynchronen Webanwendung zu erkennen, müssen Sie möglicherweise einige Änderungen an der Standardserverkonfiguration vornehmen. Beachten Sie beim Konfigurieren und Stresstest Ihrer asynchronen Webanwendung Folgendes.

• Windows 7, Windows Vista, Windows 8 und alle Windows-Clientbetriebssysteme verfügen über maximal 10 gleichzeitige Anforderungen. Sie benötigen ein Windows Server-Betriebssystem, um die Vorteile asynchroner Methoden unter hoher Last zu sehen.

• Registrieren Sie .NET 4.5 mit IIS über eine Befehlszeile mit erhöhten Rechten mithilfe des folgenden Befehls:
  %windir%\Microsoft.NET\Framework64 \v4.0.30319\aspnet_regiis -i
  Siehe ASP.NET IIS-Registrierungstool (Aspnet_regiis.exe)

• Möglicherweise müssen Sie den HTTP.sys Warteschlangengrenzwert von 1.000 auf 5.000 erhöhen. Wenn die Einstellung zu niedrig ist, wird möglicherweise HTTP.sys Anforderungen mit einem HTTP-503-Status ablehnen. So ändern Sie den HTTP.sys Warteschlangengrenzwert:

  • Öffnen Sie den IIS-Manager, und navigieren Sie zum Bereich "Anwendungspools".
  • Klicken Sie mit der rechten Maustaste auf den Zielanwendungspool, und wählen Sie "Erweiterte Einstellungen" aus.
    
  • Ändern Sie im Dialogfeld "Erweiterte Einstellungen " die Warteschlangenlänge von 1.000 auf 5.000.
    

  Beachten Sie in den obigen Bildern, dass .NET Framework als v4.0 aufgeführt ist, auch wenn der Anwendungspool .NET 4.5 verwendet. Um diese Diskrepanz zu verstehen, sehen Sie sich Folgendes an:

• .NET-Versionsverwaltung und Multi-Targeting - .NET 4.5 ist ein direktes Upgrade auf .NET 4.0

• Festlegen einer IIS-Anwendung oder eines AppPools für die Verwendung von ASP.NET 3.5 anstelle von 2.0

• .NET Framework-Versionen und Abhängigkeiten

• Wenn Ihre Anwendung Webdienste verwendet oder System.NET, um mit einem Back-End über HTTP zu kommunizieren, müssen Sie möglicherweise das connectionManagement/maxconnection-Element erhöhen. Für ASP.NET Anwendungen ist dies durch das AutoConfig-Feature auf 12 mal die Anzahl der CPUs beschränkt. Das bedeutet, dass Sie auf einem Quad-Proc höchstens 12 * 4 = 48 gleichzeitige Verbindungen zu einem IP-Endpunkt haben können. Da dies an autoConfig gebunden ist, besteht die einfachste Möglichkeit, maxconnection in einer ASP.NET-Anwendung zu erhöhen, darin, System.Net.ServicePointManager.DefaultConnectionLimit programmatisch in der Application_Start-Methode in der Datei "global.asax" festzulegen. Ein Beispiel finden Sie im Beispieldownload.

• In .NET 4.5 sollte der Standardwert von 5000 für MaxConcurrentRequestsPerCPU einwandfrei sein.

Beitragende

• Levi Broderick
• Tom Dykstra
• Brad Wilson
• HongMei Ge