Da stimme ich Ricka nicht zu. Asynchrone DB-Befehle sind nicht nur gut, sie sind entscheidend für das Erreichen von Skalierung und Durchsatz und Latenz. Sein Einwand bezüglich der Ramp-up-Zeit des Thread-Pools gilt nur für einen Webserver mit geringem Verkehrsaufkommen.
In einer Situation mit hohem Datenverkehr (die die einzige ist, die zählt) muss der Thread-Pool nicht auf das „Injizieren“ neuer Threads warten. Die asynchrone Ausführung der SQL-Befehle ist nicht nur im Hinblick auf den Zustand der Webserveranforderungen/-threads wichtig, sondern auch im Hinblick auf die Gesamtlebensdauer/-latenz der Anforderungen:Unkorrelierte DB-Aufrufe können parallel und nicht sequenziell ausgeführt werden. Dies allein führt normalerweise zu dramatischen Verbesserungen der Latenz der HTTP-Anforderung, wie sie der Benutzer erfährt. Mit anderen Worten, Ihre Seiten werden schneller geladen.
Ein Ratschlag:SQL Command ist nicht wirklich asynchron, bis Sie Asynchronous Processing=true
auf der Verbindungszeichenfolge. Dies ist zwar nicht festgelegt (und standardmäßig auch nicht), Bearbeiten:ab .NET Framework <4.5. Asynchronous Processing wird nicht mehr benötigt
) Ihre „asynchronen“ Aufrufe an BeginExecuteReader
nichts als eine Täuschung sind, wird der Aufruf einen Thread starten und das blockieren Faden. Wenn echte asynchrone Verarbeitung in der Verbindungszeichenfolge aktiviert ist dann ist der Aufruf wirklich asynchron und der Rückruf basiert auf dem IO-Abschluss.
Ein Wort der Vorsicht:Ein asynchroner SQL-Befehl wird abgeschlossen, sobald der erste Das Ergebnis wird an den Client zurückgegeben, und Info-Meldungen zählen als Ergebnis.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Sie haben alle Vorteile von Async verloren. Der print erstellt ein Ergebnis, das an den Client zurückgesendet wird, der den asynchronen Befehl abschließt und die Ausführung auf dem Client wieder aufnimmt und mit „reader.Read()“ fortfährt. Nun das wird blockiert, bis die komplexe Abfrage beginnt, Ergebnisse zu produzieren. Sie fragen 'wer print setzt im Verfahren?' aber der print kann in etwas anderem getarnt sein, vielleicht etwas so Unschuldiges wie ein INSERT das ohne ausgeführt wird erste Ausgabe eines SET NOCOUNT ON
.
