Puissance brute

I/O RPG et SQL. Pour établir ce point de référence, j’ai chronométré la commande suivante, qui charge tous les enregistrements du fichier Master en mémoire :

SetObjAcc Obj(Master) +

ObjType(*File) +

Pool(*Job)

Elle a pris environ 20 secondes, soit environ 329.000 enregistrements par minute. Elle a utilisé 9.120 transferts avec une taille moyenne de 17 Ko environ. Il faut garder cette cible à l’esprit lorsqu’on examine le reste des résultats.

Un test complémentaire nous donne une idée du temps de traitement utilisé par les systèmes d’I/O RPG et SQL une fois que les données du fichier sont en mémoire. Pour ce test (contrairement à la plupart des autres), j’ai utilisé la commande SetObjAcc illustrée ci-dessus avant les tests, afin qu’aucun transfert du disque en mémoire ne soit nécessaire pour les données. Par conséquent, les résultats du test n’indiquent que le temps nécessaire pour copier les données dans les mémoires-tampons de l’application et pour les formater pour renvoi au programme. Ces tests montrent les performances obtenues en lisant 100.000 enregistrements par ordre d’arrivée (c’est-à-dire leur ordre physique dans le fichier). Le test RPG a utilisé un code opération Read et le test SQL a ouvert un curseur et utilisé les instructions Fetch monoligne ou multiligne (figure 1). Le programme de test SQL comportait un paramètre que je pouvais définir pour indiquer la valeur de RowsPerFetch pour les instructions Fetch multiligne.

Les résultats du benchmark de la figure 2 donnent deux enseignements importants sur les performances de l’accès par ordre d’arrivée quand toutes les données du fichier sont en mémoire :

· Le fait de définir une valeur SeqOnly optimale sur la commande OvrDbf peut améliorer spectaculairement les performances du RPG.
· Un Fetch multiligne SQL traite les enregistrements bien plus rapidement qu’un Fetch monoligne.

Dans ces tests, le paramètre SeqOnly de la commande OvrDbf contrôle la taille du bloc (en nombre d’enregistrements) copié des pages disque en mémoire vers les mémoires-tampons de l’application quand on utilise un Read RPG ou un Fetch monoligne SQL. Pour un Fetch multiligne, le nombre de lignes indiquées dans l’instruction Fetch contrôle la taille du bloc, plutôt que le paramètre SeqOnly (ignoré pour un Fetch multiligne). En général, il faut utiliser le blocage lorsqu’on lit des enregistrements dans l’ordre d’arrivée.

Un Fetch multiligne SQL traite les enregistrements bien plus rapidement qu’un Fetch monoligne.

Dans d’autres exécutions de ces tests (dont les résultats ne figurent pas ici), j’ai examiné un large éventail de tailles de Fetch et constaté que les performances s’amélioraient rapidement en définissant une taille de 1, 2, 5, 11, 22, 44, puis 88 lignes, après quoi les performances n’augmentaient que légèrement puis se stabilisaient avec une taille de 176, 354, 702 et 1.408 lignes. J’ai également comparé l’utilisation de *Fixed, plutôt que *Calc, pour les pools de mémoire *Base et *Interact et constaté que *Calc donnait un résultat meilleur de deux à sept pour cent que *Fixed.

On peut combiner les résultats du test SetObjAcc…Pool(*Job) et des tests RPG et SQL pour obtenir une cible de performances pour traiter la totalité du fichier depuis le disque. Avec les meilleures performances RPG, les 109.698 enregistrements de la mémoire ont été lus en 15,6 secondes. Si l’on ajoute cela aux 20 secondes nécessaires pour transférer le fichier en mémoire avec la commande SetObjAcc, on obtient un total de 35,6 secondes pour un débit effectif d’environ 185.000 enregistrements par minute. Pour SQL, un calcul similaire donne un temps total de 43 secondes pour un débit d’environ 150.000 enregistrements par minute.