Sql Sql Server Sql Server 2005

Comprendre le mystère du temps d’attente des requêtes

C’est un scénario frustrant auquel de nombreux développeurs sont confrontés : une requête s’exécute parfaitement dans SQL Server Management Studio (SSMS) mais expire dans votre application web. Ce comportement déroutant soulève la question : Pourquoi cela se produit-il ?

Dans cet article de blog, nous allons démêler la complexité des problèmes de temps d’attente lors des appels de procédures stockées depuis une application web, en particulier celles construites avec ASP.NET 2.0 et SQL Server 2005. Vous apprendrez pourquoi la même requête peut donner des résultats significativement différents dans des environnements différents et quelles mesures vous pouvez prendre pour résoudre ce problème efficacement.

Le problème en question

Lorsque vous rencontrez un temps d’attente lors de l’exécution d’une requête via votre application web mais que vous constatez qu’elle fonctionne sans problème dans SSMS, cela peut résulter de plusieurs différences sous-jacentes. Voici un bref retour sur le scénario :

  • Vous exécutez une procédure stockée depuis une application web, et elle expire.
  • Vous vérifiez la même procédure dans SSMS, et elle s’exécute en moins d’une seconde.

Cette incohérence pousse les développeurs à chercher des réponses, car ils veulent s’assurer que leurs applications fonctionnent efficacement et sans interruption.

Analyse des paramètres de connexion

Découverte des différences

L’une des principales raisons pour lesquelles ce problème de temps d’attente se produit est liée aux différents paramètres de connexion que les applications .NET utilisent par rapport à ceux de SSMS. En analysant les paramètres de connexion via SQL Profiler, vous pourriez remarquer des paramètres spécifiques qui sont configurés différemment, par exemple :

-- protocole réseau : TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed

Paramètre clé : ARITHABORT

Parmi ces paramètres, l’option arithabort joue un rôle crucial dans les performances des requêtes. Ce paramètre affecte la manière dont SQL Server traite certaines opérations et est particulièrement lié à la capacité de l’optimiseur de requête à choisir un plan d’exécution efficace. Dans de nombreux cas, changer arithabort de off à on peut améliorer radicalement les performances, comme observé dans des scénarios pratiques où le temps d’exécution d’une requête est passé de 90 secondes à seulement 1 seconde.

Sniffing de paramètres

Le problème de temps d’attente est également lié à un concept appelé sniffing de paramètres. C’est lorsque SQL Server choisit un plan de requête basé sur les paramètres initiaux passés lors du premier appel. Si le contexte d’exécution réel change en raison de paramètres ou de paramètres de connexion différents, le plan précédemment choisi peut ne pas être optimal pour les exécutions suivantes, entraînant des ralentissements et des temps d’attente.

Mise en œuvre des solutions

Alignement des paramètres de connexion

Pour lutter contre le problème de temps d’attente, vous pouvez mettre en œuvre les stratégies suivantes :

  • Aligner les paramètres de connexion : Avant d’exécuter des requêtes, vous pouvez vous assurer que les paramètres de connexion utilisés dans l’application web correspondent à ceux de SSMS. Cela peut impliquer de spécifier manuellement des paramètres tels que set arithabort on dans votre procédure stockée ou votre code d’application.

  • Tester chaque paramètre : Vous pouvez isoler chaque paramètre de connexion et tester son impact. Apportez des modifications, reconnectez-vous et observez les différences de vitesse d’exécution ou les occurrences de temps d’attente.

Utiliser WITH RECOMPILE

Comme solution temporaire, surtout pour les rapports où le temps d’exécution n’est pas critique, vous pouvez exécuter la procédure stockée avec l’option WITH RECOMPILE. Cela oblige SQL Server à créer un nouveau plan d’exécution chaque fois que la procédure stockée est exécutée, en tenant compte des changements de paramètres. Cependant, soyez prudent avec cette approche pour les requêtes exécutées fréquemment, car la recompilation peut introduire des surcharges et des retards supplémentaires.

Conclusion

Les problèmes de temps d’attente lors de l’exécution de requêtes depuis des applications web peuvent souvent être attribués à des divergences dans les paramètres de connexion, en particulier avec des propriétés telles que arithabort. En comprenant l’impact de ces paramètres et les effets du sniffing de paramètres, les développeurs peuvent mettre en œuvre des solutions pour atténuer efficacement les problèmes de performance.

Avec une attention particulière à ces nuances, vous pouvez vous assurer que vos applications web fonctionnent de manière optimale et offrent aux utilisateurs une expérience fluide.

Dernières réflexions

Si vous rencontrez des problèmes de temps d’attente similaires ou si vous avez des perspectives issues de vos propres expériences, nous vous encourageons à partager dans les commentaires ci-dessous !