Les performances d’un job batch dépendent de deux critères

travail effectuée en comptant
le nombre d’opérations logiques d’I/O disque survenues pendant la durée du job.

Les opérations logiques d’I/O disque permettent de compter les accès aux fichiers
de de données pour l’OS/400 Data Management.

Pour collecter les données nécessaires à  l’évaluation des performances de l’application,
on peut utiliser soit le moniteur de performances de l’OS/400, soit « Collection
Services » (depuis la V4R4). Pour chaque job, il faut

? le nom du job

? l’ID utilisateur

? le numéro du job

? le temps écoulé du job

? le temps CPU requis

? le nombre d’opérations physiques d’I/O disque

? le nombre d’opérations d’I/O logiques disque (si l’on connaît le nombre d’enregistrements
base de données en entrée primaire (le nombre d’enregistrements de comptes clients
traités, par exemple), on utilisera cette valeur au lieu du comptage d’enregistrements
d’I/O logiques disque.)

Il faut également connaître le temps CPU total utilisé pour tous les jobs et tâches
système pendant l’exécution du (des) job(s) en question, le nombre d’intervalles
de collecte et la durée de chacun d’eux. Le système réunit ces informations et
les stocke dans le fichier QAPMJOBS du Performance Monitor ou dans le fichier
QAPMJOBL de « Collection Services », dans la bibliothèque de collecte des données
de performances.

Enfin, il faut connaître le modèle de la CPU et son code caractéristique ainsi
que le nombre de CPU utilisées. Ces données se trouvent dans les lignes d’en-tête
de tous les rapports de Performance Tools.

Avec tous ces chiffres, il est plus facile de déterminer le type de performances
attendues après modification. Par souci de simplicité, on suppose que le ou les
job(s) batch s’exécutent de façon autonome de sorte que l’application dispose
de toute la capacité de la CPU. Si ce n’est pas le cas, il faut estimer le pourcentage
utilisé par d’autres jobs et revoir à  la baisse les performances espérées en conséquence.

Si l’on connaît le nombre d’enregistrements à  traiter dans le test, il faut utiliser
cette valeur pour établir le débit et le coût des ressources. L’application peut,
par exemple, comporter un seul job (ou une chaîne de jobs individuels s’exécutant
l’un après l’autre) qui traite 100.000 enregistrements de comptes clients (CC)
à  l’heure. On peut vouloir établir une norme pour les taux de débit et d’utilisation
des ressources. Le taux de traitement ramené à  une seconde est de 27,7 CC/seconde
(100.000/3.600). Si le job a utilisé 1.000 secondes de temps de CPU pour traiter
les enregistrements, le coût de ressources CPU est de 10 millisecondes par enregistrement
CC (1.000/100.000).

Définir ses ambitions

Quelles sont les performances de l’application ? En utilisant notre exemple, supposons
qu’il faille multiplier par cinq la charge de travail d’origine dans le même temps

(une heure). Il faut donc traiter 500.000 enregistrements à  l’heure. Il faut aussi
utiliser 5.000 secondes de temps de CPU (puisque le temps de CPU par enregistrement
CC était de 10 millisecondes).

Il faut donc se demander :

1. Le temps CPU disponible est-il suffisant pour effectuer le travail dans le
délai prescrit ?

2. Que faut-il faire pour multiplier par cinq le débit ?

3. Combien de bras de disques sont nécessaires pour maintenir le débit sans que
les disques deviennent un goulot d’étranglement ?