Discussion :

[Vonziz]

Bonjour à tous,

Je suis confronté à un problème cornéllien sur mon application.

J'ai eu des remontées utilisateurs sur un problème de performance sur un écran de recherche de mon application web ASP.NET / SQL Server 2008 R2.

Nous avons optimisé la requête SQL via SSMS pour passer dans un temps d'exécution avoisinant les 3 secondes.

Mais nous avons eu de nouveaux retours utilisateur nous informant que le problème n'était pas résolu.

Quand je regarde ma requête de 3 secondes sous SQL Server Profiler (pour voir le temps d'exécution C# applicatif), je me suis rendu compte que le temps d'exécution de cette même requête était de 40 secondes.

Comment cela est-ce possible?

Je précise que c'est exactement le même code qui est exécuté (j'ai C/C la requête de SQL Server Profiler dans SSMS).

Merci d'avance de votre aide.

[DotNetMatt]

Est-ce que tu compares bien les mêmes valeurs entre SSMS et SQL Server Profiler ? Question bête, mais c'est juste pour être sûr que la comparaison se fait bien sur des chiffres comparables

Quel provider utilises-tu pour ton application C# ?

[Vonziz]

Hello et merci de ta réponse.

Alors je ne peux que comparer les mêmes valeurs car j'ai fais un copier coller de la requête dans les traces de SQL Server Profiler.

En provider, je suis sur du provider de base du framework .NET (utilisation de SqlCommand du namespace System.Data.SqlClient).

Aurais-tu une piste à me donner?
Toute idée est bonne à prendre.

[DotNetMatt]

Des pistes il peut y en avoir plusieurs. Il faut d'abord noter qu'il y a des différences entre la connexion établie par SSMS et celle établie par ton application. Il y a également une différence dans les instructions SET qui passent.

En principe SQL Server Profiler te permet de voir les différences (il faut regarder juste avant le passage de la requête).

Une autre chose à prendre en compte c'est qu'il y a peut-être un effet de cache avec SSMS. Si la première exécution de la requête est lente, et que les suivantes sont très rapides, c'est que les résultats sont mis en cache, ce qui peut donc fausser ta comparaison de perfs.

[Vonziz]

Merci de ton retour.

De quelle manière peut-on désactiver ces mécasnisme de cache sous SSMS pour se mettre dans une situation quasi applicative?

[DotNetMatt]

Déjà je pense qu'il faut que tu vérifies si le cache t'impacte effectivement. Pour vider le cache, tu peux passer le code suivant :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
USE <YOURDATABASENAME>;
GO
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GO

(source : Clearing Cache for SQL Server Performance Testing)

Je te suggère de le passer une fois, puis de relancer une fois ta requête et de noter le temps d'exécution. Refais ça 3 ou 4 fois et compare les résultats.

Ensuite tu peux faire le test d'exécuter 5 fois ta requête, en prenant soin au préalable de vider le cache avant chaque exécution. Ensuite tu compares les résultats.

[EDIT] : en fouillant un peu sur Google, je suis tombé sur ça : Slow in the Application, Fast in SSMS? Understanding Performance Mysteries