Verwenden asynchroner Methoden in ASP.NET 4.5

von Rick Anderson

In diesem Tutorial erfahren Sie die Grundlagen zum Erstellen einer asynchronen ASP.NET Web Forms-Anwendung mit Visual Studio Express 2012 für Web, einer kostenlosen Version von Microsoft Visual Studio. Sie können auch Visual Studio 2012 verwenden. Die folgenden Abschnitte sind in diesem Tutorial enthalten.

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

Ein vollständiges Beispiel für dieses Tutorial unter
https://github.com/RickAndMSFT/Async-ASP.NET/ auf der GitHub-Website .

ASP.NET 4.5-Webseiten in Kombination mit .NET 4.5 können Sie asynchrone Methoden registrieren, die ein Objekt vom Typ Task zurückgeben. Mit .NET Framework 4 wurde ein asynchrones Programmierkonzept eingeführt, das als Aufgabe bezeichnet wird, und ASP.NET 4.5 unterstützt Task. Aufgaben werden durch den Tasktyp und verwandte Typen im System.Threading.Tasks-Namespace dargestellt. Die .NET Framework 4.5 baut auf dieser asynchronen Unterstützung mit den Schlüsselwörtern await und asynchron auf, die das Arbeiten mit Task-Objekten wesentlich weniger komplex machen als frühere asynchrone Ansätze. Die await Schlüsselwort (keyword) ist eine syntaktische Kurzform, die angibt, dass ein Codeteil asynchron auf einen anderen Codeabschnitt warten soll. Die asynchrone Schlüsselwort (keyword) stellt einen Hinweis dar, mit dem Sie Methoden als aufgabenbasierte asynchrone Methoden kennzeichnen können. Die Kombination aus await, async und dem Task-Objekt erleichtert Ihnen das Schreiben von asynchronem Code in .NET 4.5. Das neue Modell für asynchrone Methoden wird als Aufgabenbasiertes asynchrones Muster (TAP) bezeichnet. In diesem Tutorial wird davon ausgegangen, dass Sie mit der asynchronen Programmierung unter Verwendung von Await - und asynchronen Schlüsselwörtern und dem Task-Namespace vertraut sind.

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

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

Verarbeiten von Anforderungen durch den Threadpool

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

Dies ist möglicherweise kein Problem, da der Threadpool groß genug sein kann, um viele ausgelastete Threads aufzunehmen. Die Anzahl der Threads im Threadpool ist jedoch begrenzt (das Standardmaximum für .NET 4.5 beträgt 5.000). In großen Anwendungen mit hoher Parallelität von Anforderungen mit langer Ausführungsdauer sind möglicherweise alle verfügbaren Threads ausgelastet. Diese Bedingung wird als Threadmangel (Starvation) bezeichnet. Wenn diese Bedingung erreicht ist, stellt der Webserver Anforderungen in die Warteschlange. Wenn die Anforderungswarteschlange voll ist, lehnt der Webserver Anforderungen mit einem HTTP 503-status (Server zu ausgelastet) ab. Der CLR-Threadpool hat Einschränkungen für neue Threadeinschleusungen. Wenn die Parallelität bursty ist (d. h. ihre Website kann plötzlich eine große Anzahl von Anforderungen erhalten) und alle verfügbaren Anforderungsthreads aufgrund von Back-End-Aufrufen mit hoher Latenz ausgelastet sind, kann die begrenzte Threadeinschleusungsrate 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 warten, bei denen der Threadpool auf den .NET 4.5-Standardwert von 5.000 Threads anwächst, würde etwa 5 GB mehr Arbeitsspeicher verbrauchen als eine Anwendung, die dieselben Anforderungen mit asynchronen Methoden und nur 50 Threads für den Dienst verwenden kann. Wenn Sie asynchron arbeiten, verwenden Sie nicht immer einen Thread. Wenn Sie beispielsweise eine asynchrone Webdienstanforderung stellen, verwendet ASP.NET keine Threads zwischen dem Aufruf der asynchronen Methode und dem Await. Die Verwendung des Threadpools für Dienstanforderungen mit hoher Latenz kann zu einem großen Arbeitsspeicherbedarf und einer schlechten Auslastung der Serverhardware führen.

Verarbeiten von asynchronen Anforderungen

In Webanwendungen, bei denen beim Starten eine große Anzahl gleichzeitiger Anforderungen angezeigt wird oder die eine Burstlast aufweisen (bei der die Parallelität plötzlich zunimmt), erhöht das asynchrone Ausführen von Webdienstaufrufen die Reaktionsfähigkeit Ihrer Anwendung. Die Verarbeitung einer asynchronen Anforderung dauert genau so lange wie die einer synchronen Anforderung. Wenn eine Anforderung beispielsweise einen Webdienstaufruf ausführt, der zwei Sekunden benötigt, 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 wartet, bis die erste Anforderung abgeschlossen ist. Daher verhindern asynchrone Anforderungen das Anforderungswarteschlangen- und Threadpoolwachstum, wenn es viele gleichzeitige Anforderungen gibt, 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; Untersuchen 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 Vorgänge sind einfach oder haben eine kurze Ausführungszeit.
• Einfachheit ist wichtiger als die Effizienz.
• Die Vorgänge beanspruchen hauptsächlich die CPU und bringen keine umfangreiche Datenträger- oder Netzwerkauslastung mit sich. Die Verwendung asynchroner Methoden für CPU-gebundene Vorgänge bietet keine Vorteile und führt zu mehr Mehraufwand.

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

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

• Die Vorgänge sind netzwerkgebunden oder E/A-gebunden und nicht CPU-gebunden.

• Parallelverarbeitung ist wichtiger als die Einfachheit des Codes.

• Sie möchten einen Mechanismus bereitstellen, der Benutzern das Abbrechen einer Anforderung mit langer Laufzeit ermöglicht.

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

• Tests zeigen, dass die blockierenden Vorgänge einen Engpass bei der Standortleistung darstellen und dass 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 soll keine Referenzarchitektur für die asynchrone Programmierung in ASP.NET sein. Das Beispielprogramm ruft ASP.NET-Web-API Methoden auf, die wiederum Task.Delay aufrufen, um lange ausgeführte Webdienstaufrufe zu simulieren. Die meisten Produktionsanwendungen weisen keine so offensichtlichen Vorteile für die Verwendung asynchroner Methoden auf.

Nur wenige Anwendungen erfordern, dass alle Methoden asynchron sind. Die Konvertierung einiger synchroner Methoden in asynchrone Methoden ermöglicht häufig die beste Effizienzsteigerung für den erforderlichen Arbeitsaufwand.

Die Beispielanwendung

Sie können die Beispielanwendung auf 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 nutzt. Der meiste Code für dieses Tutorial stammt aus diesem Projekt.
• WebAPIpgw: Das ASP.NET MVC 4-Web-API-Projekt, das die Products, Gizmos and Widgets Controller implementiert. Sie stellt die Daten für das WebAppAsync-Projekt und das Mvc4Async-Projekt bereit.
• Mvc4Async: Das ASP.NET MVC 4-Projekt, das den in einem anderen Tutorial verwendeten Code enthält. Sie führt Web-API-Aufrufe an den WebAPIpwg-Dienst aus.

Die synchrone Gizmos-Seite

Der folgende Code zeigt die synchrone Methode, mit der Page_Load eine Liste von Gizmos angezeigt 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 der Controller.
Die folgende Abbildung zeigt die Gizmos-Seite aus dem Beispielprojekt.

Erstellen einer asynchronen Gizmos-Seite

Das Beispiel verwendet die neuen Schlüsselwörter asynchron und await (verfügbar in .NET 4.5 und Visual Studio 2012), damit der Compiler für die Verwaltung der komplizierten Transformationen verantwortlich ist, die für die asynchrone Programmierung erforderlich sind. Mit dem Compiler können Sie Code mithilfe der synchronen Ablaufkonstrukte von C# schreiben, und der Compiler wendet automatisch die Transformationen an, die für die Verwendung von Rückrufen erforderlich sind, um das Blockieren von Threads zu vermeiden.

ASP.NET asynchronen Seiten müssen die Page-Anweisung enthalten, deren Async Attribut auf "true" festgelegt ist. Der folgende Code zeigt die Page-Anweisung , deren Async Attribut für die Seite GizmosAsync.aspx auf "true" festgelegt ist.

<%@ 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 ist.

• Für die Page-Anweisung muss das Async Attribut auf "true" festgelegt sein.
• 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 der asynchronen Schlüsselwort (keyword) gekennzeichnet, die den Compiler angibt, Rückrufe für Teile des Textkörpers zu generieren und automatisch ein Task zurückgegebenes zu erstellen.
• "Async" wurde an den Namen der asynchronen Methode angefügt. Das Anfügen von "Async" ist nicht erforderlich, ist jedoch die Konvention beim Schreiben asynchroner Methoden.
• Der Rückgabetyp der neuen GetGizmosSvcAsync Methode ist Task. Der Rückgabetyp von Task stellt die laufende Arbeit dar und stellt Aufrufern der -Methode ein Handle bereit, über das auf den Abschluss des asynchronen Vorgangs gewartet werden kann.
• Die await Schlüsselwort (keyword) wurde auf den Webdienstaufruf angewendet.
• Die asynchrone Webdienst-API wurde (GetGizmosAsync) aufgerufen.

Innerhalb des GetGizmosSvcAsync Methodentexts wird eine andere asynchrone Methode GetGizmosAsync aufgerufen. GetGizmosAsync gibt sofort einen Task<List<Gizmo>> zurück, der schließlich abgeschlossen wird, wenn die Daten verfügbar sind. Da Sie nichts anderes tun möchten, bis Sie über die Gizmo-Daten verfügen, wartet der Code auf die Aufgabe (mithilfe des await-Schlüsselwort (keyword)). Sie können die await-Schlüsselwort (keyword) nur in Methoden verwenden, die mit der asynchronen Schlüsselwort (keyword) versehen sind.

Der await-Schlüsselwort (keyword) blockiert den Thread erst, wenn die Aufgabe abgeschlossen ist. Es 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, ruft sie diesen Rückruf auf und setzt die Ausführung der Methode direkt dort fort, wo sie aufgehört hat. Weitere Informationen zur Verwendung der Schlüsselwörter await und async sowie 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 gizmosAsync vorgenommen wurden.

• Die Methodensignatur wurde mit dem asynchronen Schlüsselwort (keyword) versehen, der Rückgabetyp wurde in Task<List<Gizmo>>geändert, und Async wurde an den Methodennamen angefügt.
• Anstelle der synchronen WebClient-Klasse wird die asynchrone HttpClient-Klasse verwendet.
• Die await Schlüsselwort (keyword) wurde auf die asynchrone HttpClientGetAsync-Methode angewendet.

Die folgende Abbildung zeigt die asynchrone Gizmo-Ansicht.

Die Browserdarstellung der gizmos-Daten ist identisch mit der Ansicht, die durch den synchronen Aufruf erstellt wurde. Der einzige Unterschied besteht darin, dass die asynchrone Version unter hohen Lasten möglicherweise leistungsfähiger ist.

RegisterAsyncTask-Hinweise

Mit eingebundene RegisterAsyncTask Methoden 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 nicht mehr die volle Kontrolle darüber, wann Ereignisse ausgeführt werden. Beispielsweise, wenn sowohl eine ASPX-Datei als auch eine . Masterdefinitionsereignisse Page_Load , und eines oder beide sind asynchron, die Ausführungsreihenfolge kann nicht garantiert werden. Für Ereignishandler (z async void Button_Click . B. ) gilt die gleiche unbestimmte Reihenfolge.

Paralleles Ausführen mehrerer Vorgänge

Asynchrone Methoden haben gegenüber synchronen Methoden einen erheblichen Vorteil, wenn eine Aktion mehrere unabhängige Vorgänge ausführen muss. Im bereitgestellten Beispiel zeigt die synchrone Seite PWG.aspx(for Products, Widgets and Gizmos) die Ergebnisse von drei Webdienstaufrufen an, um eine Liste mit Produkten, Widgets und Gizmos abzurufen. 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, benötigt die asynchrone PWGasync.aspx-Seite etwas mehr als 500 Millisekunden, während die synchrone PWG Version über 1.500 Millisekunden benötigt. 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 PWGasync Code hinter ist unten dargestellt.

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 Ansicht, die von der asynchronen PWGasync.aspx-Seite zurückgegeben wird.

Verwenden eines Abbruchtokens

Asynchrone Methoden, die Taskzurückgegeben werden, sind abbrechbar, d. h. sie nehmen einen CancellationToken-Parameter an, wenn einer mit dem AsyncTimeout Attribut der Page-Direktive bereitgestellt wird. Der folgende Code zeigt die Seite GizmosCancelAsync.aspx mit einem Timeout für die Sekunde.

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

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

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);
    }
}

Wenn Sie in der bereitgestellten Beispielanwendung den Link GizmosCancelAsync auswählen, wird die Seite GizmosCancelAsync.aspx aufgerufen und der Abbruch (durch Timeout) des asynchronen Aufrufs veranschaulicht. Da die Verzögerungszeit innerhalb eines zufälligen Bereichs liegt, müssen Sie die Seite möglicherweise mehrmals aktualisieren, um die Timeout-Fehlermeldung zu erhalten.

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

Um die Vorteile einer asynchronen Webanwendung zu nutzen, müssen Sie möglicherweise einige Änderungen an der Standardserverkonfiguration vornehmen. Beachten Sie Folgendes, wenn Sie Ihre asynchrone Webanwendung konfigurieren und testen.

• Windows 7, Windows Vista, Windows 8 und alle Windows-Clientbetriebssysteme haben 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 Eingabeaufforderung 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 das HTTP.sys Warteschlangenlimit von dem Standardwert 1.000 auf 5.000 erhöhen. Wenn die Einstellung zu niedrig ist, wird möglicherweise HTTP.sys Anforderungen mit einem HTTP 503-status abgelehnt. So ändern Sie das HTTP.sys Warteschlangenlimit:

  • Ö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 in 5.000.
    

  Beachten Sie in den obigen Bildern, dass .NET Framework als v4.0 aufgeführt wird, obwohl der Anwendungspool .NET 4.5 verwendet. Um diese Diskrepanz zu verstehen, lesen Sie folgendes:

• .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 oder System.NET verwendet, 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 wird dies durch die AutoKonfigurationsfunktion auf das 12-fache der Anzahl von 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 zum Erhöhen maxconnection in einer ASP.NET-Anwendung darin , System.Net.ServicePointManager.DefaultConnectionLimit programmgesteuert in der from-Methode Application_Start in der Datei global.asax festzulegen. Ein Beispiel finden Sie im Beispieldownload.

• In .NET 4.5 sollte der Standardwert 5000 für MaxConcurrentRequestsPerCPU in Ordnung sein.

Beitragende

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