Test de l'évolutivité des procédures stockées

J'ai une application de messagerie électronique qui sera appelée à fournir à l'interface utilisateur le nombre de nouveaux messages pour un utilisateur donné à chaque chargement de page. J'ai quelques variantes de choses que je teste au niveau de la base de données, mais toutes sont résumées par l'appel de proc stocké.

J'essaie de claquer la base de données pour voir quel serait le point de rupture (nombre de demandes par seconde).

En un mot, j'ai une table telle que cet userId, newMsgCount avec un index clusterisé sur userId. SQL devrait être en mesure de gérer des centaines ou des milliers de ces réponses par seconde. Je pense que le retardataire est mon application .NET.

Comment puis-je en faire un bon test pour obtenir les résultats du test en fonction des performances SQL?

Existe-t-il un outil pour cela que je puisse lui donner un nom de proc stocké et un paramètre pour qu'il ponde ma base de données?

Je veux voir si la DB peut retourner un min. de 250 réponses par seconde.

SQLQueryStress est un excellent outil pour les tests de concurrence à petite échelle, mais il n'est pas vraiment à la hauteur des tests de charge. Un ensemble d'outils étonnamment peu connu est disponible gratuitement, de Microsoft, qui peut faire face à la plupart des scénarios de test de stress SQL Server, les utilitaires RML .

Un très bref aperçu des outils:

• ReadTrace convertit les traces Profiler des fichiers .trc en .rml (Replay Markup Language).
• OStress est utilisé pour relire les fichiers .rml et .sql sur un serveur.
• ORCA (OStress Replay Control Agent) coordonne la relecture entre les instances distribuées d'OStress.
• Reporter fournit des rapports d'analyse des performances.

Il existe un excellent article de démarrage rapide de l'équipe SQLCat qui comprend un exemple de base de données et de charges de travail, Precision Performance for Microsoft SQL Server using RML Utilities 9.0

Vous avez le choix entre l'activité de profilage pour la relecture ou, peut-être plus appropriée dans votre scénario, le lancement manuel d'un ensemble de scripts .sql que vous pouvez ensuite relire via OStress et ORCA.

Excellents outils pour les tests de charge et les problèmes de performances.

Un outil que vous pouvez utiliser est SQLQueryStress . Pour un démarrage rapide, fournissez: la procédure stockée, les itérations et le nombre de threads. Commencez ensuite les tests de résistance. Des métriques comme les secondes CPU, les lectures logiques, etc ... seront affichées.

On dirait que vous êtes un développeur .NET. Une façon serait d'écrire une petite application qui utilise le multithreading et d'avoir juste une quantité définie de hits simultanés dans la base de données et la procédure stockée. Exécutez une trace pendant que cela se produit.

Écrivez le code d'application pour incrémenter la quantité de threads simultanés sur un intervalle spécifique si vous souhaitez augmenter automatiquement la charge sur SQL Server.

C'est ainsi que je procéderais.