Ist Task.Run eine schlechte Praxis in einer ASP .NET MVC-Webanwendung?

Hintergrun

Wir entwickeln derzeit eine Webanwendung, die auf ASP .NET MVC 5, Angular.JS 1.4, Web API 2 und Entity Framework 6 basiert. Aus Gründen der Skalierbarkeit hängt die Schwere der Webanwendung vom Async / Wartet-Muster ab. Unsere Domain erfordert einige CPU-intensive Berechnungen, die einige Sekunden (<10s) dauern können. In der Vergangenheit haben einige Teammitglieder Task.Run verwendet, um die Berechnungen zu beschleunigen. Da das Starten eines zusätzlichen Threads in ASP .NET MVC- oder Web API-Controllern als eine schlechte Vorgehensweise angesehen wird (der Thread ist dem IIS nicht bekannt, also nicht) bei AppDomain Recycle berücksichtigt => SieheStephen Clearys Blog-Beitrag) verwendeten sie ConfigureAwait (false).

Beispie
public async Task CalculateAsync(double param1, double param2)
{
    // CalculateSync is synchronous and cpu-intensive (<10s)
    await Task.Run(() => this.CalculateSync(param1, param2))).ConfigureAwait(false);
}
FrageHat die Verwendung von Task.Run in einem asynchronen Web-API-Controller für CPU-gebundene Vorgänge einen Leistungsvorteil? Vermeidet ConfigureAwait (false) wirklich die Erstellung eines zusätzlichen Threads?

Antworten auf die Frage(8)

Ihre Antwort auf die Frage