L'exécution d'une même requête à partir de C # VS SSMS donne un temps d'exécution différent

J'ai une demande comme celle-ci

SELECT 
[EstimateId], 
[CreationUserId], 
[EstimateStatusValueId], 
[LanguageId], 
[LocationId], 
[EstimatorUserId], 
[FilterUnitSystemTypeId], 
[EstimateNumber], 
[RevisionNumber], 
[CreationDate], 
[ModificationDate], 
[ProjectDescription], 
[IsBsdq], 
[ClosingDate], 
[ClosingTime], 
[ClosingUpdatedOn], 
[DeadLineDate], 
[IsReceived], 
[Inclusion], 
[Exclusion], 
[Misc], 
[Note], 
[WorkDeadLines], 
[Comments], 
[Validity], 
[PlansLocation], 
[PlansReceivedFrom], 
[Price]
FROM [Estimate].[Estimates] 
ORDER BY [ClosingDate] ASC, [ClosingTime] ASC

Lorsque j'exécute cette requête dans SSMS, j'obtiens un temps d'exécution de 953 ms, mais lorsque j'exécute cette requête à partir d'une requête Linq dans mon C #, j'obtiens un temps d'exécution de 1813 ms.

La requête Linq utilise le ".Net SqlClient Data Provider" et est émise contre EntityFramework (fichier EDMX). Est-ce que cela peut être un problème?

Quelqu'un sait-il pourquoi j'ai une grande différence entre les temps d'exécution de ces demandes qui sont les mêmes mais s'exécutent à partir d'un contexte différent par rapport à la même base de données?

J'ai vérifié tous les plans d'exécution des deux requêtes et ils utilisent le même index pour satisfaire leur requête respective.

Pour voir le plan d'exécution de la demande C #, j'utilise le profileur SQL pour intercepter l'événement Show Plan XML et je le compare à celui de SSMS et les deux sont les mêmes.

sql-server-2008 database-tuning

— Nico
source

juste une petite question - pourquoi sélectionnez-vous toutes les données du tableau sans aucune condition de recherche? Avez-vous vraiment besoin de toutes les données de l'application sans aucun filtrage?

— Marian

Oui, c'est une fonctionnalité dont j'ai besoin, mais cette fonctionnalité ne sera pas utilisée souvent. Je sais que ce n'est pas optimal pour émettre une grande requête sans clause where.

— Nico

Quoi qu'il en soit, ma préoccupation n'est pas la demande elle-même mais la différence entre les temps d'exécution. Je vous montre cette requête mais toutes les requêtes donnent des résultats similaires. Pourquoi ?

— Nico

Réponses:

Est-ce cohérent, maintes et maintes fois?

Je vois une différence de CPU qui pourrait être du temps de compilation. Y a-t-il des paramètres LINQ qui affectent cela?

Éditer:

Capturez les plans dans Profiler
Êtes-vous sûr que le SQL est le même dans Profiler ?

— gbn
source

Oui, c'est constant à chaque fois. Je ne sais pas pour les paramètres linq. mais j'ai trouvé ce lien codeproject.com/KB/cs/linqsql2.aspx

— Nico

Vous pouvez voir le plan dans l'image ci-dessus pour les deux requêtes. Oui, je suis sûr que le SQL est le même dans le profileur. SQL, Profiler, SSMS et l'application C # sont tous hébergés sur mon ordinateur à des fins de développement.

— Nico

Capturez le plan réel en XML depuis Profiler. Pas du cache. Vous avez des réponses différentes mais vous montrez un plan différent = mauvais plan indiqué ci-dessus peut-être

— gbn

Je pense que le problème réside dans l'utilisation du fichier EDMX pour générer des requêtes à partir de l'application C #.

J'ai trouvé ces liens qui expliquent le cas.

Projet de code

Stackoverflow-1

Stackoverflow-2

— Nico
source

Vous voudrez regarder les plans d'exécution pour les deux requêtes et voir où ils sont différents.

— mrdenny
source

je viens de modifier mon message ... et je vérifie déjà que les deux requêtes utilisent le même plan.

— Nico

J'ajoute juste l'événement que vous m'avez dit dans profiler et c'est la même chose que ma dernière demande que je poste dans ma question. J'ai les mêmes plans .. toute autre idée ...

— Nico

Tout semble correct. La seule chose qui pourrait l'expliquer serait que l'application .NET ne reçoive pas les données assez rapidement. Le temps indiqué dans SQL Profiler inclut le temps nécessaire pour transférer les données du serveur vers le client. Donc, si le client ne télécharge pas tout assez rapidement, le temps d'exécution signalé sera plus long.

— mrdenny

Il s'agit ensuite de savoir ce que l'application fait avec les données et comment elle lit les données de la base de données.

— mrdenny

À l'appui de la réponse de mrdenny, j'ajouterais que j'ai testé une requête dans 3 clients SQL différents et que leurs heures signalées étaient toutes différentes bien que les statistiques d'E / S et l'exécution des plans soient identiques. Tout cela était dû à la manière interne dont les clients traitaient les données. Je crois que vous pouvez obtenir différents résultats temporels en sortant dans un fichier, dans la grille de Management Studio ou dans la sortie de texte. Quoi qu'il en soit, d'après ce dont je me souviens, la documentation indiquait que SQL sera toujours plus rapide que LINQ to SQL, ce n'est donc pas une surprise :-).

— Marian