Не съм съгласен с Ricka по този въпрос. Async DB командите са не само добри, те са критични за постигане на мащаб, пропускателна способност и латентност. Възражението му относно времето за нарастване на пула от нишки се отнася само за уеб сървър, който изпитва нисък обем трафик.
В ситуация с голям трафик (което е единственото, което има значение), пулът от нишки няма да трябва да чака за „инжектиране“ на нови нишки. Изпълнението на SQL командите асинхронно е важно не само от гледна точка на заявките/нишките на уеб сървъра, но и от гледна точка на общия живот/закъснение на заявката:некорелираните DB извиквания могат да се извършват паралелно, за разлика от последователно. Само това обикновено води до драматични подобрения в латентността на HTTP заявката, както се усеща от потребителя. С други думи, вашите страници се зареждат по-бързо.
Един съвет обаче:SQL командата не е наистина асинхронна, докато не активирате Asynchronous Processing=true
на низа за свързване. Въпреки че това не е зададено (и по подразбиране не е, Редактиране:започвайки с .NET Framework <4.5. Asynchronous Processing вече не се изисква
) вашите „асинхронни“ извиквания към BeginExecuteReader
не са нищо друго освен измама, обаждането ще стартира нишка и ще блокира това резба. Когато истинската асинхронна обработка е активирана в низа за връзка тогава повикването е наистина асинхронно и обратното извикване се основава на завършване на IO.
Внимание:асинхронна SQL команда завършва веднага след първата резултатът се връща на клиента и информационните съобщения се броят за резултат.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Загубихте всички предимства на async. print създава резултат, който се изпраща обратно на клиента, който завършва async командата и изпълнението на клиента се възобновява и продължава с 'reader.Read()'. Сега това ще блокира, докато сложната заявка започне да дава резултати. Питате „кой поставя print в процедурата?' но print може да е маскиран в нещо друго, може би нещо толкова невинно изглеждащо като INSERT който се изпълнява без първо издаване на SET NOCOUNT ON
.
