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

[darkelend]

Est ce que ta requête utilise des paramètres ? Est ce que ton application lance d'autres requêtes simultanément sur les mêmes objets ?

[Vonziz]

darkelend, oui et oui.

DotNetMatt, je vais faire les tests et je te dis.

[darkelend]

- Comment passes tu les paramètres à la requête ? En concatenant tout dans un string ou en utilisant les SqlParameter ?
- Pour les autres requêtes, il faudrait voir si tu n'as pas un lock. Tu peux le voir avec profiler par exemple.

[Vonziz]

Bon j'avance dans mon analyse.

DotNetMatt, le vidage du cache de SSMS avant le passage de la requête la fait passer à 20 secondes.

Mais je suis toujours sur un ordre de 40 secondes avec mon application ASP.net.

darkelend, mes paramètres sont passés via SQLParam en effet, ce qui donne une requête de la forme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
exec sp_executesql N'-- ./ma_page
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
 
SELECT COUNT(*)
<le reste de ma requete>
 
SELECT *
<le reste de ma requete>
 
SET TRANSACTION ISOLATION LEVEL read committed',
N'@timestamp datetime,@searchString varchar(8000),@contact_id int,@date_from datetime,@date_to datetime',
@timestamp='2013-09-11 14:02:53.450',
@searchString=NULL,
@contact_id=447,
@date_from=NULL,
@date_to=NULL

Avez-vous d'autres pistes d'analyse pour arriver à un temps d'exécution iso-applicatif et ainsi, garantir mon optimisation via SSMS?

[DotNetMatt]

Regarde le second lien que je t'ai posté (Slow in the Application, Fast in SSMS? Understanding Performance Mysteries) tu as plein de scénarios que tu peux tester.

Avant de te lancer, tu peux aussi regarder si ça ne vient pas des instructions SET. Lance le profiler puis exécute ta requête. Juste avant le passage de la requête, tu dois pouvoir récupérer ces instructions.

Ensuite dans ton appli, exécute les avant ta requête pour voir si ça change quelque chose ou pas...

[SQL_EVAN]

J'ai déjà eu ce genre de problème. Cela venait de l'option ARITHABORT.

Essayer de faire un SET ARITHABORT ON dans la transaction lancée depuis le C#

Si ça marche et ça vous intéresse vous allez trouver plus de détails ici

[mikedavem]

Cela peut effectivement venir d'un paramètre de session différent entre ton application et SSMS.

Ce que je ferais c'est comparer les 2 requêtes avec le profiler ou les événements étendus avec les options de sessions + plan d'exécution utilisé par chaque requête

++