110
Chapitre 5. Analyse des performances
Figure 5.11 — Deuxième onglet des options de replay
Dans le premier, reproduit sur la figure 5.11, vous désactivez l’exécution d’instructions lancée par des sessions système pour ne garder que le comportement des
sessions utilisateur. Vous pouvez n’exécuter que les instructions d’un SPID, en
sachant que le même SPID peut être réutilisé par des sessions différentes, l’une après
l’autre. Vous pouvez indiquer les intervalles de temps des événements de la trace qui
doivent être rejoués. La partie Health Monitor permet de configurer un thread du
Profiler pour tuer automatiquement les processus qui sont bloqués depuis un nombre
défini de secondes. La valeur d’attente 0 signifie que le profiler ne tuera aucun processus bloqué. Nous traitons de la surveillance de processus bloqués dans la
section 7.5.
Test de charge
La capacité de rejouer des traces est intéressante pour faire un test de charge, sur un
serveur de test ou sur un serveur final avant une mise en production, à l’aide d’une
trace représentative de l’activité réelle ou prévue du serveur. Vous pouvez ouvrir
plusieurs fois la même trace, et la rejouer à partir d’instances différentes du profiler,
ou même de machines clientes différentes. Cette approche pose un problème : il faut
s’assurer que la trace ne comporte pas d’instructions qui ne peuvent être rejouées
plus d’une fois, notamment des insertions explicites de valeurs vérifiées par des
contraintes d’unicité. Si c’est le cas, vous pouvez soit les retirer de la trace, soit les
encapsuler dans des transactions que vous terminez en ROLLBACK. Dans les deux cas,
la gestion du replay devient plus, voire trop, contraignante.
Chapitre 5. Analyse des performances
Figure 5.11 — Deuxième onglet des options de replay
Dans le premier, reproduit sur la figure 5.11, vous désactivez l’exécution d’instructions lancée par des sessions système pour ne garder que le comportement des
sessions utilisateur. Vous pouvez n’exécuter que les instructions d’un SPID, en
sachant que le même SPID peut être réutilisé par des sessions différentes, l’une après
l’autre. Vous pouvez indiquer les intervalles de temps des événements de la trace qui
doivent être rejoués. La partie Health Monitor permet de configurer un thread du
Profiler pour tuer automatiquement les processus qui sont bloqués depuis un nombre
défini de secondes. La valeur d’attente 0 signifie que le profiler ne tuera aucun processus bloqué. Nous traitons de la surveillance de processus bloqués dans la
section 7.5.
Test de charge
La capacité de rejouer des traces est intéressante pour faire un test de charge, sur un
serveur de test ou sur un serveur final avant une mise en production, à l’aide d’une
trace représentative de l’activité réelle ou prévue du serveur. Vous pouvez ouvrir
plusieurs fois la même trace, et la rejouer à partir d’instances différentes du profiler,
ou même de machines clientes différentes. Cette approche pose un problème : il faut
s’assurer que la trace ne comporte pas d’instructions qui ne peuvent être rejouées
plus d’une fois, notamment des insertions explicites de valeurs vérifiées par des
contraintes d’unicité. Si c’est le cas, vous pouvez soit les retirer de la trace, soit les
encapsuler dans des transactions que vous terminez en ROLLBACK. Dans les deux cas,
la gestion du replay devient plus, voire trop, contraignante.