Je ne suis pas d'accord avec Ricka sur ce point. Les commandes de base de données asynchrones ne sont pas seulement bonnes, elles sont essentielles pour atteindre l'échelle, le débit et latence. Son objection concernant le temps de montée en puissance du pool de threads ne s'applique qu'à un serveur Web qui connaît de faibles volumes de trafic.
Dans une situation de trafic élevé (qui est la seule qui compte), le pool de threads n'aura pas à attendre "l'injection" de nouveaux threads. L'exécution asynchrone des commandes SQL est importante non seulement du point de vue de la santé des requêtes/threads du serveur Web, mais également du point de vue de la durée de vie/latence totale des requêtes :les appels de base de données non corrélés peuvent être effectués en parallèle, par opposition à séquentiellement. Cela seul entraîne généralement des améliorations spectaculaires de la latence de la requête HTTP telle que vécue par l'utilisateur. En d'autres termes, vos pages se chargent plus rapidement.
Un conseil cependant :la commande SQL n'est pas vraiment asynchrone tant que vous n'activez pas Asynchronous Processing=true
sur la chaîne de connexion. Bien que cela ne soit pas défini (et ne l'est pas par défaut, Modifier :à partir de .NET Framework <4.5. Asynchronous Processing n'est plus nécessaire
) vos appels "asynchrones" à BeginExecuteReader
ne sont rien d'autre qu'une imposture, l'appel lancera un fil et bloquera cela fil de discussion. Lorsque le véritable traitement asynchrone est activé dans la chaîne de connexion alors l'appel est vraiment asynchrone et le rappel est basé sur l'achèvement des E/S.
Un mot d'avertissement :une commande SQL asynchrone se termine dès que le premier le résultat revient au client et les messages d'information comptent comme résultat.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Vous avez perdu tous les avantages d'async. Le print crée un résultat qui est renvoyé au client, qui termine la commande asynchrone et l'exécution sur le client reprend et continue avec le 'reader.Read()'. Maintenant ça bloquera jusqu'à ce que la requête complexe commence à produire des résultats. Vous demandez 'qui met print dans la procédure ?' mais le print peut être déguisé en quelque chose d'autre, peut-être quelque chose d'aussi innocent qu'un INSERT qui s'exécute sans émettre d'abord un SET NOCOUNT ON
.
