Trouver des goulots d'étranglement au niveau des performances sur un site Web classique de serveur ASP/SQL

Question

J'ai une ancienne application serveur asp/sql classique qui lance constamment 500 erreurs/timeouts même si la charge n'est pas énorme. Certaines requêtes de base de données sont assez intensives, mais rien ne devrait les faire tomber.

Y a-t-il de bons logiciels que je peux installer sur mon serveur et qui vont montrer précisément où se trouvent les goulets d'étranglement dans l'ASP ou la DB?

Answer 1

Avez-vous essayé d'exécuter le SQL Server Profiler sur le serveur? Il mettra en évidence toute activité inattendue qui frappe la base de données à partir de l'application ainsi que l'aide à l'identification des requêtes mal exécutées.

Answer 2

Si vous êtes satisfait du fait que les requêtes de base de données sont intensivement nécessaires, vous devrez peut-être définir des délais d'expiration plus appropriés sur les pages qui utilisent ces requêtes.

Définissez Server.ScriptTimeout sur quelque chose de plus grand, vous devrez peut-être également définir le délai d'attente sur les objets de commande ADO utilisés par le script.

Answer 3

Certains outils que vous pouvez essayer: (éditions Enterprise uniquement)

• HP (anciennement Mercury) LoadRunner ou Performance Center
• Visual Studio Application Center Test
• outil Microsoft Web Application Stress (aka WAS, alias "Homer" ; prédécesseur de Application Center Test)
• WebLoad
• MS Visual Studio Analyzer si vous voulez suivre le code de l'application. Cela peut vous indiquer combien de temps l'application attend sur les appels de base de données et quel était le SQL utilisé. Vous pouvez ensuite utiliser le profileur SQL pour régler les requêtes.

Answer 4

Où se produit le délai d'expiration? Est-ce qu'il y a des lignes quand ASP se connecte/exécute sql? Si oui, votre problème est soit avec la connexion au serveur db ou à la base de données elle-même. Chargez SQL profiler dans MSSQL pour voir combien de temps les requêtes prennent. Peut-être est-ce dû à des verrous dans la base de données.

Utilisez-vous des transactions? Si c'est le cas, assurez-vous qu'ils ne verrouillent pas votre base de données pendant longtemps. Assurez-vous que vous utilisez des transactions dans ADO et non sur la page ASP entière. Vous pouvez également ignorer le verrouillage dans les sélections SQL en utilisant l'indicateur WITH (NOLOCK) sur les tables.

Assurez-vous que votre base de données est optimisée avec des index.

Assurez-vous également que vous êtes connecté à la base de données pour le temps le plus court possible (exemple: code qui ne fonctionne pas): conn.open; set rs = conn.execute(); rs.close; conn.close. Donc, stockez les jeux d'enregistrements dans une variable au lieu de boucler tout en maintenant la connexion à la base de données ouverte. Un bon moyen est d'utiliser la fonction GetRows() dans ADO.

Toujours fermer et définir explicitement les objets ADO à rien. Cela peut entraîner la connexion à la base de données pour rester ouverte.

Activer la mise en pool des connexions.

constantes de charge d'ADO dans global.asa si vous les utilisez

Ne pas stocker des objets dans des étendues de session ou d'application.

Mise à jour vers les dernières versions de ADO, MDac, service packs SQL Server, etc.

Êtes-vous sûr que le serveur peut gérer la charge? Peut-être mettre à jour? Est-ce sur un hébergement partagé? Peut-être que votre application n'est pas le problème.

Il est assez simple de mesurer une performance de script en la programmant de la ligne 1 à la dernière ligne. De cette façon, vous pouvez identifier les pages à exécution lente.

Answer 5

Voici comment je l'aborderais.

1. Examinez les tâches en cours d'exécution sur le serveur. Qui prend plus de temps CPU - SQL Server ou IIS? La plupart du temps, ce sera un serveur SQL et ça sonne certainement comme ça en fonction de votre message. Il est très rare que toute application ASP fasse beaucoup de traitement sur le côté ASP des choses, par opposition aux côtés COM ou SQL. Utilisez le Générateur de profils SQL pour extraire toutes les requêtes envoyées au serveur de base de données à l'aide de SQL Profiler.

2. Traiter d'abord le fruit à portée de main. En règle générale, vous aurez quelques requêtes "problèmes" qui frappent fréquemment la base de données et grignotent beaucoup de temps. Traiter avec ceux-ci. (Un truisme dans le développement de logiciel est que 10% du code mâche 90% du temps d'exécution ...)

En plus d'examiner les coûts de la requête avec SQL Profiler et Analyseur de requêtes/SQL Studio et faire le travail de détection de performances SQL normal, vous pouvez également vérifier si vos appels de base de données retournent des quantités de données excessives à votre code ASP. J'ai vu des cas où des requêtes d'apparence inoffensive renvoyaient d'énormes quantités de données inutiles à ASP - le type de requête classique ("select * from tablename") écrit par des programmeurs paresseux/inexpérimentés qui renvoie 10 000 lignes énormes lorsque le programmeur avait vraiment besoin champ d'une rangée. La raison pour laquelle je mentionne ce cas particulier est que ces types de requêtes ont souvent de faibles temps d'exécution et de faibles coûts de requêtes sur le côté SQL des choses et peuvent donc glisser sous le radar.