forte utilisation a été identifié
par la supervision du niveau 2. Les figures 11, 12 et 13 contiennent
quelques-unes des questions auxquelles
il est répondu pendant l’activité
du niveau 3, les mesures à  collecter
et les rapports types.
D’autres outils permettent une collecte
de données supplémentaires :
Database Monitor, Performance Explorer
(PEX) de Performance Tools/ 400
(PT/400), et routines de journalisation
des temps de transaction écrites localement.
Les outils potentiels pour
produire des rapports sont les suivants
:PT/400, rapports iSeries Navigator
SQL Monitor, Visual Explain,
iDoctor PEX Analyzer, PTDV, outils
tierce partie et requêtes personnalisées.
Lorsque vous planifiez les outils de
diagnostic à  utiliser, songez à  plusieurs stratégies utiles. Les deux règles les
plus importantes sont les suivantes :

• L’intuition est mauvaise conseillère
  pour trouver la cause des problèmes
  de performances ou leur solution.
  Utilisez toujours quelques mesures
  techniques pour confirmer les
  causes d’un problème et pour vérifier
  que votre solution fonctionne (et
  qu’elle n’entraîne pas d’autres problèmes).

• Avant de corriger un problème de
  performance, assurez-vous qu’il en
  vaut la peine. Là  encore, utilisez une
  technique de mesure quantitative
  pour sélectionner vos efforts d’optimisation
  et pour déterminer leur
  priorité.

Il est bon également d’ajouter du
code « d’instrumentation » à  vos applications
afin de pouvoir capturer les
données d’utilisation et de performance
liées à  des fonctions d’application
spécifiques. Par exemple, dans le
cas d’une application de traitement
transactionnel interactive, vous pouvez
ajouter du code chargé de générer des
entrées de journalisation de performances
(comme écrire des enregistrements
dans un fichier) qui capturent
des informations telles que les types de
transactions, les données saisies, les résultats,
et le temps écoulé. Ce type de
code d’instrumentation doit être
conçu de telle sorte que l’on puisse
l’activer et le désactiver selon les besoins,
sans être obligé de recréer des
objets programme. La journalisation
dynamique des performances propres
aux applications est un moyen précieux
pour suivre efficacement les
sources des problèmes de performances.
Pour certaines fonctions applicatives,
le benchmarking est un bon
moyen de mesure de performance relative.
Le benchmarking convient particulièrement
dans le cas de fonctions
non interactives à  calculs intensifs.
Ainsi, si vos applications appellent une
routine pour une application financière complexe, vous pouvez écrire un
driver qui appelle de façon répétitive
cette routine avec une plage de valeurs.
Vous pouvez utiliser un tel
benchmark de plusieurs manières.
L’exécution d’un benchmark permet
d’estimer approximativement le
temps et les ressources qu’utilise une
fonction particulière. Ainsi, si une routine
chargée d’une opération financière
complexe dure en moyenne un
quart de milliseconde par appel, et si la
routine est appelée deux millions de
fois au maximum dans votre job batch
le plus long, l’optimisation peut procurer
un gain potentiel d’environ huit minutes.
Ce genre d’évaluation permet
de décider si cette routine est digne,
ou non, du travail d’optimisation.
Pendant un benchmark, vous pouvez
aussi utiliser des outils de performance
comme PEX, pour mesurer
quelles ressources sont en service et
quelles parties du code contribuent le
plus au temps d’exécution. L’exécution
de benchmarks avant et après est aussi
un moyen de juger des résultats du travail
d’optimisation, du réglage du système
ou d’un nouveau matériel.
Il est plus difficile d’appliquer des
benchmarks fiables à  des applications
interactives ou Web. Attention aussi
aux benchmarks autonomes de routines
lourdes en I/O base de données :
on risque des résultats trompeurs, dus
au caching par exemple.