Qu'est-ce que SNIReadSyncOverAsync et pourquoi faudrait-il beaucoup de temps pour le compléter?
sur notre ASP.Net site web,nous avons eu quelques demandes de délai. AppDynamics montre que les appels de procédure SQL reviennent en quelques secondes, mais nous passons plus de 100 secondes dans SNIReadSyncOverAsync.
est-ce que quelqu'un sait ce qu'est / fait cette méthode et pourquoi cela prendrait autant de temps? Nous n'utilisons pas L'EF qui est référencé dans chaque question / post que j'ai pu trouver à ce sujet.
Merci à avance
mise à Jour
Cela fait longtemps et bien que nous n'ayons jamais trouvé de solution quant à la raison pour laquelle tout ce temps était passé à SNIReadSyncOverAsync, j'ai quelques idées.
je pense que dans ce cas, c'était peut-être la façon dont la version spécifique D'AppDynamics rapportait le temps passé sur les appels SQL, mais je n'ai pas de données réelles pour étayer cela, juste mon hypothèse de ce que j'ai observé. Nous avons finalement cessé de voir l'heure rapportée comme étant passé dans SNIReadSyncOverAsync et il s'est déplacé vers les requêtes elles-mêmes chronométrage.
cela n'a pas fait beaucoup de depuis parce que les mêmes requêtes s'exécuteraient instantanément dans SSMS sur la même base de données.
la réponse ultime a fini par être liée à ARITHABORT ce qui a fait notre application et SSMS d'utiliser deux plans d'exécution différents (voir https://dba.stackexchange.com/a/9841), expliquant pourquoi nous ne pouvions pas reproduire les temps morts avec SSMS.
une fois que nous avons résolu cela, nous avons été en mesure d'identifier quelques parties de la procédure qui avait besoin d'être ajustée et nous n'avons pas couru dans les temps morts inexpliqués ou SNIReadSyncOverAsync depuis.
3 réponses
pas sûr si vous avez déjà résolu cela, mais: SNI est L'Interface réseau du serveur SQL, et la méthode mentionnée existe dans la plupart des ADO.NET piles d'appels complètes qui attendent les données du serveur SQL. Cela est indépendamment du fait que la mise en œuvre de niveau supérieur est EF, raw ADO.NET ou peu importe.
Je ne suis pas sûr de ce que métrique ou Appdynamique de signal utilise pour capturer l'achèvement d'une exécution de procédure stockée, mais vous pourriez voir ce genre de comportement si votre procédure stockée complète relativement vite, mais la transmission du résultat de la requête du serveur à votre client prend un certain temps.
Sans en savoir plus sur votre infrastructure, il est très difficile d'aider les autres. Si le problème persiste, je recommande l'exécution de la même requête dans SQL Server Management studio avec les statistiques définies temps de marche et" Include Client Statistics " activé. Peut-être que ces chiffres vous donneraient une idée sur le fait de savoir si le transfert de données est réellement le problème.
dans mon cas, C'était en effet, comme le mentionne Jouni, une transmission très lente des résultats de la requête. J'utilise Automapper pour préparer des données à envoyer au client. Donc, il n'est pas clair quelle propriété exacte a causé la charge, mais pour être sûr que j'ai coupé tous les composés que je n'ai pas besoin de montrer du côté du client. (À l'origine, j'avais besoin d'une collection à afficher en grille du côté du client. L'exécution est devenue très rapide.
j'ai rencontré un problème similaire - il s'avère que SqlDataReader.Disposer peut se coincer pour très long temps si vous cassez tôt de large select.