Warum sollten asynchrone Controller verwendet werden, wenn IIS bereits die Parallelität von Anfragen behandelt?

Async / await in asp.net geht es nicht um Parallelität, es geht darum, Threads zu blockieren oder nicht zu blockieren.

Wenn Sie async / awaite verwenden, geben Sie den Thread frei, während Sie auf eine Operation warten. Wenn diese Operation CPU-gebunden ist, gibt es keinen Vorteil (es wird sogar etwas langsamer wegen der Kontextwechsel)

Wenn die Operation jedoch IO-gebunden ist (Netzwerk, Festplatte, ...), bedeutet dies, dass IIS mehr gleichzeitige Anfragen verarbeiten kann, da Sie keine Threads blockieren, die nichts tun.

Wie andere bereits erwähnt haben, erlaubt async dem Anfrage-Thread, während er einen asynchronen Vorgang ausführt, zum Thread-Pool zurückzukehren. Mit synchronen Handlern endet Ihr Server mit Threads, die auf E / A blockiert sind, was im Wesentlichen nichts Wichtiges bewirkt, aber auch nicht für andere Anfragen verwendet werden kann, während sie blockiert sind. async gibt nur diese Threads frei, so dass sie immer nützlich sind.

Also, die erste Frage ist, dass die Frage " async oder der Thread-Pool" die falsche Frage ist. Wenn Sie async verwenden, erlauben Sie ASP.NET, den vorhandenen Threadpool maximal zu nutzen. async verwendet die vorhandene (parallele) Parallelität in ASP.NET und fügt (asynchrone) Parallelität hinzu, um eine höhere Skalierbarkeit zu erreichen.

Aber die Frage bleibt von "warum"? Die Gründe sind zweifach: async kann weiter skalieren als (nur) der Thread-Pool und async ist auch reaktionsfähiger. Wie in den Kommentaren zu den anderen Antworten erwähnt, sind Threads ziemlich schwergewichtige Objekte, die unnötig verschwendet werden müssen; Der Speicher für asynchrone Operationen ist viel weniger als der von einem Thread verwendete Speicher. Der zweite Grund ist auch wichtig: Wenn ein plötzlicher Burst von Anfragen hereinkommt, kann der Thread-Pool (an sich) nur begrenzt expandieren; async ermöglicht dem Thread-Pool, Anfragen viel effizienter zu behandeln.

Wenn Sie die Anfrage bearbeiten, werden Sie wahrscheinlich auf Ressourcen zugreifen, die sehr viel Zeit benötigen (z. B. dauert die Hin- und Rückfahrt zu einer Datenbank wahrscheinlich mehrere Millisekunden, oft langsamer).

Wenn Sie synchrone Vorgänge verwenden, um diese Ressourcen abzurufen, wird der Verarbeitungsthread blockiert, bis dieser IO abgeschlossen ist.

Wenn asynchrone Operationen verwendet werden, kann derselbe IIS-Thread für etwas Nützlicheres verwendet werden, während die E / A abgeschlossen ist. In Websites mit höherer Auslastung kann dies eine erhebliche Skalierbarkeitsdifferenz darstellen.