Discussion :

[Tozoul]

Bonjour,

Je suis en framework 3.5 avec VS2008 IIS6 et SQL 2005.
Mon application est full web.

J'ai écris une procédure stockée qui executé directement dans SQL Server Management s'exécute entre 1 et 4 secondes suivant le cache.

Quand j'execute la même procédure stockée avec les même paramètres via le C# j'arrive en timeout (plus de 30 secondes).

Je ne comprend pas comment peut s'expliquer une telle différence de temps d'exécution.
Voici la commande passée en C#

Code :

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

IDataReader rdr = this.DbProvider.ExecuteReader(command)

Pour information ma requete remonte a peine 310 lignes.

Si quelqu'un peut m'aider car la je suis coincé.

Merci.
Tozoul

[Nicolas Esprit]

Bonjour,

Ne serait-ce pas un Timeout au niveau de la connexion plutôt qu'au niveau de la requête ? Quelle est l'exception renvoyée précisément ?

[cybermaxs]

Salut,
En premeir, il doit y avoir un Timeout sur la commande (30 sec par défaut). Ensuite comment utilises tu le reader ? Il est très important de la fermer (Close) à la fin de ton traitement.

[Tozoul]

Bonjour,

Effectivement, le timeout est du à la connexion (30s) mais ma question est surtout orienté dans le problème de performance entre un appel depuis le requeteur et un appel en C# qui prend au moins 10 fois plus de temps.

Appel d'une même requête avec les même paramètres :
- SQL Management : entre 1 et 4 secondes
- Depuis le C# : timeout au bout des 30 secondes.

Et je n'arrive pas à comprendre les différence de performance entre les deux.

[cybermaxs]

Bonjour,

Effectivement, le timeout est du à la connexion (30s) mais ma question est surtout orienté dans le problème de performance entre un appel depuis le requeteur et un appel en C# qui prend au moins 10 fois plus de temps.

Appel d'une même requête avec les même paramètres :
- SQL Management : entre 1 et 4 secondes
- Depuis le C# : timeout au bout des 30 secondes.

Et je n'arrive pas à comprendre les différence de performance entre les deux.

Est ce que ramènes tout dans SQL Management ?
Je vois que tu n'a pas beaucoup de ligne, mais sont elles de tailles importantes (colonnes blob, text, ...) ?

[Tozoul]

Les enregistrements comportent 20 colonnes sans métadonnées, une majorité de texte entre 10 et 150 caractères et le reste en numérique et float.

[Nicolas Esprit]

Effectivement, le timeout est du à la connexion (30s)

Tozoul,

Il ne faut pas confondre le CommandTimeout et le ConnectionTimeout. Le premier intervient lorsque la requête executée prend trop de temps, le second lorsque la tentative de connexion à ton SGBD dépasse le délai.

Un Timeout lors de la connexion ne signifie pas que ta requête n'est pas performante ! Généralement, executer une requête SQL en passant par C# donne un temps d'execution assez semblable à celui d'une requête executée directement dans SQL Management ( après, il y a quand même quelques écarts, croissants avec le volume de données, mais ça ne représente rien pour 310 lignes).

Peut être un problème avec la ConnectionString ?

[cybermaxs]

Au risque de me répéter et en suivi du post de Nicolas, ta connexion reste ouverte tant que tu n'as pas fermé le reader via Close. Le DataReader fait partie du "mode connecté". Peux tu nous dire ce que tu fais avec ce reader ?

[Tozoul]

Je m'exprime surement pas correctement mais je n'arrive pas à ouvrir le reader car ma procédure stockée n'arrive pas à finir par contre ma connexion à la base de données ne rentre pas de problème.

Mon problème est lié à l'execution de la procédure stockée qui est en arrive en timeout mais ma connexion est toujours ouverte sur ma BDD.

Je n'arrive dont pas à ouvrir mon datareader et donc il ne reste pas ouvert. En plus, je le créer avec un using.

Merci de votre aide

[cybermaxs]

Je m'exprime surement pas correctement mais je n'arrive pas à ouvrir le reader car ma procédure stockée n'arrive pas à finir par contre ma connexion à la base de données ne rentre pas de problème.

Mon problème est lié à l'execution de la procédure stockée qui est en arrive en timeout mais ma connexion est toujours ouverte sur ma BDD.

Je n'arrive dont pas à ouvrir mon datareader et donc il ne reste pas ouvert. En plus, je le créer avec un using.

Merci de votre aide

ah ok.
Mise à part un problème sur les EntLiv, il faudrait vérifier la commande que tu lui passes. Un exemple ?

Il faudrait aussi vérifier qu'une autre commande passe bien, sans TimeOut.

[Tozoul]

Voici l'exemple pour la création de la commande

Code :

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

1
2
3
4
5
6
7
8
9
10
 
            DbCommand command = db.GetStoredProcCommand("dbo._sp_Bundle_SearchActiveBundleActivitiesByActivityTypeSiteOrThirdPartyIDAndUserID");
            db.AddInParameter(command, "activityTypeID", DbType.Int64, activityTypeID);
            db.AddInParameter(command, "siteID", DbType.Int64, siteID);
            db.AddInParameter(command, "userID", DbType.Int64, userID);
            db.AddInParameter(command, "thirdPartyID", DbType.Int64, thirdPartyID);
            db.AddInParameter(command, "searchBundleID", DbType.Int64, searchBundleID);
            db.AddInParameter(command, "searchDocumentReference", DbType.String, searchDocumentReference);
            db.AddInParameter(command, "searchProductID", DbType.Int64, searchProductID);
            db.AddInParameter(command, "searchContainerID", DbType.Int64, searchContainerID);

Et j'ai d'autres procédure stockées qui prennent un temps "normal" pour me rendre la main.

[Tozoul]

Je pense avoir trouver une partie de l'explication, mon index n'était pas à jour.

Je viens de rebuild mon index et la procédure stockée ne tombe plus en timeout.

Mais cela n'explique pas la différence de temps entre les deux appels mais au moins cela ne me bloque plus.

Tozoul

[cybermaxs]

Je pense avoir trouver une partie de l'explication, mon index n'était pas à jour.

Je viens de rebuild mon index et la procédure stockée ne tombe plus en timeout.

Mais cela n'explique pas la différence de temps entre les deux appels mais au moins cela ne me bloque plus.

Tozoul

curieux en effet...