11
votes

SQLCOMMAND.CANCEL () provoque une augmentation de la performance?

J'ai vu cela montrer plusieurs endroits en code, jamais avec une explication, juste un commentaire cryptique au-dessus de celui-ci (déclaration et exécution incluses pour une idée de contexte. C'est juste une procédure standard d'exécution d'un SQLCOMMAND):

//SqlCommand cmd = new SqlCommand();
//cmd.ExecuteReader();
//Read off the results

//Cancel the command. This improves query time.
cmd.Cancel ();


2 commentaires

Avez-vous profilé le code? Il serait intéressant de voir combien d'une incidence en réalité.


Il y a un cas de bord important où appeler Annuler fait une grande différence - voir ma réponse ci-dessous


4 Réponses :


16
votes

Selon MSDN , c'est correct.

La méthode de fermeture se remplit dans les valeurs Pour les paramètres de sortie, les valeurs de retour et des bons enregistrés, augmentant la temps qu'il faut pour fermer un Sqldatreader qui a été utilisé pour traiter une grande ou complexe de requêtes. Quand le Valeurs de retour et le nombre de Les enregistrements affectés par une requête ne sont pas significatif, le temps qu'il faut Fermer le SQLDatreader peut être réduit en appelant la méthode d'annulation de la objet SQLCOMMAND associé avant appeler la méthode de près.

bizarre!


4 commentaires

Hein. N'a pas pensé à regarder dans la doccilareader Doc. Bonne prise!


Regardant @ le code sous-jacent, il est clair qu'il fait une juste quantité de travail à proximité, cependant, je n'imaginerais pas un instant que c'est tout ce qui est important à la fin de la journée.


J'ai appris quelque chose ;-) Bien que je suis d'accord, vous devez être sérieusement goutaré sur DB IO pour remarquer le changement.


@Lucas Heneks, merci d'avoir posté la citation. Je pense qu'il est important de noter que cmd.cancel () indique SQL Server de ne pas renvoyer les paramètres de sortie, renvoyer les valeurs ou les enregistrements. Habituellement, vous définiriez Nocount sur Désactiver l'envoi d'enregistrements de récupération et s'il existe des paramètres de sortie ou des valeurs de retour, vous souhaitez probablement les récupérer afin que je me demande sur la manière dont la technique est dans la plupart des situations.



0
votes

Notre équipe technologique à Cinchcast a fait de l'analyse comparative et nous avons constaté que l'ajout de la cmd.cancel () ralentit réellement.

Nous avons un appel DALC qui obtient une liste d'épisodes pour un hôte. Nous avons couru 1000 fois et avons eu le temps de réponse moyen pour renvoyer 10 épisodes.

Alors avec le retour 10 spectacles Moyenne avec annuler: 0.069S Moyenne sans annuler: 0.026S

À peu près beaucoup plus lentement lorsque vous courez avec 10 épisodes de retour.

Alors, j'ai encore essayé de retourner 100 épisodes pour voir si un ensemble de résultats plus large fait une différence.

Donc, avec le retour de 100 spectacles sur chaque appel Moyenne avec annulation: 0.132S Moyenne sans annuler: 0.122S

Donc, cette fois, la différence de temps était beaucoup moins. Il est encore plus rapide mais sans utiliser l'annulation de nos cas d'utilisation habituels.


0 commentaires

9
votes

appeler Annuler donne une amélioration de performance massive potentiellement si votre appel à exécuteur renvoie un grand nombre de lignes et vous don 'T lire toutes les lignes .

Illustrer, disons qu'une requête retourne un million de lignes et vous fermez le lecteur après avoir lu uniquement les 1000 premières lignes. Si vous ne parviendrez pas à appeler Annuler Avant de fermer le lecteur, la méthode fermeture sera Bloc alors qu'elle énumère en interne à travers les 999 000 lignes restantes

Essayez-le et voyez!


1 commentaires

Il ne peut pas être suffisamment surélevé à quel point le "ne lit pas toutes les lignes" est la fonction principale de cette méthode.



0
votes

Dans votre exemple, vous ouvrez le lecteur, lisez toutes les lignes, et l'annulez la commande, mais vous n'avez pas montré où le lecteur était fermé.

Assurez-vous que l'annulation arrive avant Le Dispose / Fermer . Par exemple, vous n'obtiendrez pas de renforcement des performances dans cet exemple (code réel en production, malheureusement): xxx

dommage que c'est déjà fermé par la déclaration utilisée !

Voici comment il devrait être lu pour réaliser le bénéfice potentiel: xxx

de msdn sqlcommand.cancel : < BlockQuote>

Dans certains, rares, cas, si vous appelez ExecuTereader, appelez Fermer (implicitement ou explicitement) avant d'appeler Annuler, puis appelez Annuler, la commande Annuler ne sera pas envoyée à SQL Server et que le jeu de résultats peut Continuer Pour diffuser après avoir appelé Fermer. Pour éviter cela, assurez-vous d'appeler Annuler avant de fermer le lecteur ou la connexion.


0 commentaires