Mes scénarios de test

de début et de fin, et j’ai gardé
le journal de comptage de performances
en action pendant le chargement.
J’ai ensuite redémarré le service
SQL Server pour avoir la certitude que
le caching SQL Server n’affecterait pas
le test. Ensuite, j’ai effectué le test
Database Hammer à  partir de mon
client pour trois scénarios : 100, 500 et
800 connexions. Ma première intention
était de tester 1 000 connexions, mais ma machine client a commencé à 
manifester des erreurs « thread creation
» autour de 850 connexions.
(L’application ne pouvait pas générer
plus de 850 connexions à  partir de
mon client.) Je me suis assuré que le
journal de comptage de performances
ne mesurait l’activité que quand toutes
les connexions étaient générées, en
l’arrêtant après avoir arrêté le test et en
désallouant les connexions. J’ai aussi
redémarré SQL Server avant le début
de chaque test. J’ai ensuite créé une
nouvelle base de données de test avec
les fichiers log et de données dans des
partitions séparées. En utilisant cette
base de données, j’ai répété les étapes
2 à  4 (c’est-à -dire, charger 10 millions
d’enregistrements, redémarrer le service
SQL Server et effectuer le test
Database Hammer pour 100, 500 et
800 connexions).

Conjointement aux informations
fournies par les journaux de comptage
de Performance Monitor, le Database
Hammer s’est avéré un excellent outil
pour effectuer des tests de contrainte
et il a révélé des données de performances
que je n’attendais pas.
La base de données SAN à  partition
unique a affiché un Average Disk
Queue Length plus bas pour les trois
tests. Average Disk Queue Length mesure
le nombre de requêtes de lecture
et d’écriture qui sont mises en file
d’attente pour une matrice. Pour cette
matrice RAID 5, le nombre inclut l’activité
de lecture et d’écriture moyenne
mise en file d’attente sur tous les
disques dans la matrice. La règle
consiste à  diviser l’Average Disk Queue
Length par le nombre de disques physiques
qui composent la matrice ; si le
résultat moyen dépasse 2, il y a un
risque d’engorgement d’I/O. Les résultats
de ce compteur étaient étonnants
en ce qu’une matrice provoquerait
probablement davantage d’engorgement
d’I/O que deux matrices.