V tomhle s Rickou nesouhlasím. Asynchronní příkazy DB jsou nejen dobré, ale jsou rozhodující pro dosažení rozsahu, propustnosti a latence. Jeho námitka ohledně doby náběhu fondu vláken se vztahuje pouze na webový server, který má nízké objemy provozu.
V situaci vysokého provozu (což je jediné, na čem záleží), fond vláken nebude muset čekat na „vložení“ nových vláken. Provádění SQL příkazů asynchronně je důležité nejen z hlediska stavu požadavků/vlákna webového serveru, ale také z hlediska celkové životnosti/latence požadavku:nekorelovaná DB volání lze provádět paralelně, nikoli sekvenčně. To samo o sobě obvykle vede k dramatickému zlepšení latence HTTP požadavku, jak je zažívá uživatel. Jinými slovy, vaše stránky se načítají rychleji.
Malá rada:Příkaz SQL není skutečně asynchronní, dokud nepovolíte Asynchronous Processing=true
na připojovacím řetězci. I když toto není nastaveno (a ve výchozím nastavení není, Upravit:počínaje .NET Framework <4.5. Asynchronous Processing již není vyžadován
) vaše „asynchronní“ volání BeginExecuteReader
nejsou nic jiného než podvod, hovor spustí vlákno a zablokuje to vlákno. Když je povoleno skutečné asynchronní zpracování v připojovacím řetězci pak je volání skutečně asynchronní a zpětné volání je založeno na dokončení IO.
Upozornění:asynchronní příkaz SQL se dokončuje ihned po prvním výsledek se vrátí klientovi a informační zprávy se počítají jako výsledek.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Přišli jste o všechny výhody async. print vytvoří výsledek, který se odešle zpět klientovi, který dokončí asynchronní příkaz a provádění na klientovi se obnoví a pokračuje pomocí 'reader.Read()'. Teď to se zablokuje, dokud komplexní dotaz nezačne produkovat výsledky. Ptáte se 'kdo dává print v postupu?' ale print může být maskováno v něčem jiném, možná v něčem tak nevinném jako INSERT který se spustí bez první vydání SET NOCOUNT ON
.