> Tech > Mes scénarios de test

Mes scénarios de test

Tech - Par iTPro - Publié le 24 juin 2010
email

Avant d'examiner les résultats du test Database Hammer, passons en revue les scénarios de test utilisés. J'ai commencé par créer la base de données de test avec les fichiers log et de données sur la même partition SAN. Ensuite, j'ai chargé les 10 millions d'enregistrements, en notant soigneusement les heures

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.

Téléchargez gratuitement cette ressource

Guide Azure Virtual Desktop

Guide Azure Virtual Desktop

Comment optimiser les coûts, gagner en agilité, en sécurité et en conformité avec Azure Virtual Desktop ? Découvrez, dans ce Guide Infographique, les bénéfices clés pour les utilisateurs et les avantages de la mise en œuvre pour les équipes IT.

Tech - Par iTPro - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT