2009-11-02 8 views
1

Nous avons eu d'énormes problèmes de performances lors du déploiement de notre application ASP.NET chez un client, dont la base de données reposait sur un emplacement distant.Performances ASP.NET: comptage des requêtes SQL

Nous avons trouvé que c'était dû au fait que les pages rendaient ridicule quantité de requêtes SQL individuelles à la base de données. Nous n'avons jamais remarqué de problème car généralement, le Web et la base de données sont sur le même réseau local (faible latence). Mais sur cette configuration (tout à coup) de faible latence, c'était très très lent.

(Notez que chaque requête SQL par elle-même était rapide, c'est le nombre et la nature sérielle de la séquence qui pose problème).

J'ai demandé à l'équipe d'ingénierie de pouvoir signaler et maintenir un «mur de la honte» (ou stats) nous indiquant pour chaque page le nombre de requêtes SQL afin que nous puissions l'utiliser comme référence. Ils prétendent que c'est cher ..

quelqu'un peut me dire comment être capable de maintenir ou d'obtenir un tel rapport à moindre coût et facilement?


  • Nous utilisons SQL Server 2005
  • Nous avons un mélange de notre couche d'accès DB et subsonique
  • Je sais et utiliser le profileur, mais qui est un manuel de bits. Demander ici s'il y a une astuce sur comment automatiser ou peut-être je suis juste fou?
+0

Qu'est-ce que DB est-ce? –

+0

Cet exercice devrait être trivial dans toute application moyennement bien conçue. Vous pouvez l'utiliser comme référence brute pour déterminer la qualité du code de votre application. Si quelque chose comme ça est "cher", cela devrait être un drapeau rouge. – RedFilter

+0

Cela ne répond pas à votre question, mais j'ai une suggestion pour améliorer les performances dans ce scénario. La création et la fermeture de connexions peuvent être plus coûteuses que d'habitude lorsque vous travaillez avec une base de données depuis un emplacement distant. Si vous ne l'avez pas déjà fait, ajoutez une logique qui n'ouvre qu'une seule connexion db par requête de page. L'idée serait d'utiliser une sorte de connexion globale qui s'ouvre automatiquement lorsque la première requête est faite et se ferme automatiquement lorsque l'événement Page.Unload est appelé. –

Répondre

1

Tout d'abord, consultez subsonique de BatchQuery fonctionnalité - il pourrait aider à alléger beaucoup de la contrainte dans la première coupe sans entrer dans la modification matérielle de votre code.

Vous pouvez planifier des tâches/vidages de trace à partir de la fin du serveur SQL. Vous pouvez également exécuter des compteurs Perfmon pour connaître le nombre de requêtes de base de données que l'application traite. Cela dit, j'essayerais d'encourager le client à déplacer la base de données (ou une copie en miroir de la base de données) plus près de votre application. C'est probablement la solution la moins chère à long terme, selon l'épaisseur de l'application.

3

Si vous êtes sur SQL Server, lisez le profileur.

http://msdn.microsoft.com/en-us/library/ms187929.aspx

Exécution profileur de l'interface utilisateur est cher, mais vous pouvez exécuter des traces sans l'interface utilisateur et qui vous donnera ce que vous voulez.

0

J'ai eu un bon succès en utilisant cet outil dans le passé, pas sûr si le prix est correct pour vous, mais il découvrira toutes les questions que vous pourriez avoir:

Spotlight on SQL Server

0

Le MiniProfiler (anciennement connu sous le nom de mini profileur MVC, mais il fonctionne pour tous les MVC et Webforms) est un must dans un tel cas IMO. Si le code qui crée les connexions à la base de données est bien structuré, c'est un jeu d'enfant de l'exécuter pour presque toutes les applications ASP.NET.

Il génère un rapport sur chaque page rendue avec des statistiques de profilage, y compris chaque requête SQL envoyée à la base de données pour la requête. Vous pouvez le voir en action sur les pages Stack Exchange Data Explorer (en haut à gauche).

Questions connexes