Transfert des données à  partir du disque

chaque test, pour chasser de la mémoire le contenu des
fichiers, obligeant ainsi chaque test à  retransférer toutes les données du disque.

Les figures 3a et 3b présentent les performances d’un échantillon représentatif
de tests RPG, en utilisant diverses valeurs pour les paramètres NbrRcds et SeqOnly
de la commande OvrDbf. Les deux paramètres sont définis comme un nombre d’enregistrements.
Tandis que NbrRcds est destiné à  contrôler la taille du transfert quand les données
sont déplacées du disque en mémoire, SeqOnly ne vise qu’à  contrôler la taille
des blocs copiés dans les mémoires-tampons du programme. Il s’avère que ce n’est
pas aussi simple. La figure 3a illustre l’importance d’une grande taille de transfert
et comment, pour les pools de mémoire *Fixed, la valeur NbrRcds détermine la taille
du transfert. Mais, quand on indique *Calc pour les pools de mémoire, le système
peut utiliser une taille de transfert bien plus grande que celle qui est indiquée
avec le paramètre NbrRcds. En outre, pour les deux pools *Fixed et *Calc, quand
aucun paramètre NbrRcds n’est indiqué, la valeur du paramètre SeqOnly détermine
la taille du transfert ainsi que la taille des blocs copiés dans les mémoires-tampons
du programme (figure 3b).

Avec ces observations présentes à  l’esprit, voici deux règles approximatives proposées
pour l’accès par ordre d’arrivée RPG :

· Généralement, les pools *Calc sont plus performants et moins sensibles à  des
valeurs mal choisies pour les paramètres NbrRcds et/ou SeqOnly.

· Avec les pools *Calc, on peut omettre le paramètre NbrRcds, mais il faut absolument
définir un paramètre SeqOnly(*Yes n) avec une valeur bien choisie pour n.

Dans ces tests, l’utilisation de pools *Calc et d’une valeur SeqOnly de 44 a optimisé
les performances, mais cette taille de bloc donnait d’à  peine meilleurs résultats
qu’une taille plus petite de 11, qui est le nombre d’enregistrements tenant dans
un bloc de 32 Ko. Dans une situation de production classique, où des jobs simultanés
s’affrontent pour obtenir la mémoire réelle, il faut utiliser la plus petite valeur
de SeqOnly qui fournit le gros du gain de performances (11 dans ce cas). L’utilisation
de la plus petite taille de bloc appropriée empêche le job de se comporter comme
dévoreur de mémoire et de dégrader les performances globales du système. Sachez
aussi que si vous exécutez le système avec des pools de mémoire *Fixed, il est
très important de choisir avec soin la valeur de NbrRcds.