Ik ben het hierin niet met Ricka eens. Async DB-opdrachten zijn niet alleen goed, ze zijn ook van cruciaal belang voor het bereiken van schaal, doorvoer en latentie. Zijn bezwaar over de opstarttijd van de threadpool is alleen van toepassing op een webserver die weinig verkeer ervaart.
In een situatie met veel verkeer (wat de enige is die ertoe doet), hoeft de threadpool niet te wachten op het 'injecteren' van nieuwe threads. Het asynchroon uitvoeren van de SQL-opdrachten is niet alleen belangrijk vanuit het oogpunt van de gezondheid van webserververzoeken/threads, maar ook vanuit het oogpunt van de totale levensduur/latentie van verzoeken:niet-gecorreleerde DB-aanroepen kunnen parallel worden uitgevoerd, in plaats van sequentieel. Dit alleen al resulteert meestal in dramatische verbeteringen in de latentie van het HTTP-verzoek zoals ervaren door de gebruiker. Met andere woorden, uw pagina's worden sneller geladen.
Een advies echter:SQL Command is niet echt asynchroon totdat u Asynchronous Processing=true
op de verbindingsreeks. Hoewel dit niet is ingesteld (en standaard niet, Bewerken:beginnend met .NET Framework <4.5. Asynchronous Processing is niet langer vereist
) uw 'asynchrone' aanroepen naar BeginExecuteReader
niets anders zijn dan een schijnvertoning, de oproep zal een thread starten en dat blokkeren draad. Wanneer echte asynchrone verwerking is ingeschakeld in de verbindingsreeks dan is de oproep echt async en is de callback gebaseerd op IO-voltooiing.
Een waarschuwing:een asynchrone SQL-opdracht wordt voltooid zodra de eerste resultaat keert terug naar de klant en infoberichten tellen als resultaat.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Je bent alle voordelen van async kwijt. De print creëert een resultaat dat wordt teruggestuurd naar de client, die de async-opdracht voltooit en de uitvoering op de client wordt hervat en verder gaat met de 'reader.Read()'. Nu dat wordt geblokkeerd totdat de complexe query resultaten begint te produceren. Je vraagt 'wie plaatst print in de procedure?' maar de print kan vermomd zijn in iets anders, misschien iets dat er zo onschuldig uitziet als een INSERT die zonder . uitvoert eerst een SET NOCOUNT ON uit
.