Tirez la quintessence de votre base de données grâce à  RPG & SQL !

J’ai conduit ces tests sur un AS/400 modèle 170 équipé d’un processeur 2290, de
320 Mo de mémoire centrale, et deux lecteurs de disques 6607 de 4,19 Go. J’ai
utilisé la V4R4 avec les PTF cumulatives C9230440 et les groupes de PTF de bases
de données disponibles en même temps que la cumulative. Avant de lancer les tests
comparatifs, j’ai effectué un large éventail d’essais avec la valeur système QPfrAdj
réglée sur 3 (ajustement automatique) et observé les tailles des pools de mémoire
résultants pour déterminer les tailles optimales pour les tests. Ensuite, pour
que la configuration mémoire reste homogène dans tous les tests, j’ai mis QPfrAdj
à  0 pour désactiver l’ajustement automatique et ai défini les tailles suivantes
pour les pools de mémoire :

*Machine 65 Mo

*Spool 3,5 Mo

J’ai exécuté tous les tests dans un job interactif qui utilisait les pools de
mémoire partagée *Base et *Interact. Pour la plupart des tests, j’ai réglé les
pools *Base et *Interact sur *Calc afin que le système ajuste dynamiquement les
caractéristiques de paging des pools. D’une manière générale, *Calc offre des
performances de base de données supérieures à  *Fixed (qui définit des caractéristiques
de paging fixes) ; mais j’évoque certains cas où le réglage des pools sur *Fixed
donne de meilleures performances.

Il n’y avait aucune autre activité sur le système pendant les tests. J’en ai répété
un certain nombre pour m’assurer de la cohérence des résultats obtenus. Dans une
seule suite de tests, expliquée ci-dessous, je n’ai pas obtenu de performances
constantes.

Avant chaque test destiné à  mesurer des I/O physiques (comme le transfert de données
à  partir du disque), j’ai exécuté une commande du type

SetObjAcc Obj(Master) +

Pool(*Purge)

pour effacer de la mémoire toutes les pages des fichiers de test. Sauf indication
contraire, les tests de benchmark démarrent avec le code programme (mais pas les
données de fichier) en mémoire.

J’ai mesuré les intervalles de temps écoulés en utilisant le code-opération RPG
Time exécuté dans des points appropriés des programmes de test. Avant d’ajouter
le code d’I/O aux programmes de test, je les ai compilés et exécutés pour mesurer
l’overhead des instructions de boucle, de la génération de nombres pseudo-aléatoires
(et autre code non-I/O). Après quoi, j’ai soustrait ce montant des résultats des
tests, afin que les résultats présentés soient fondés sur le temps d’I/O net.
(Le plus souvent, le temps d’overhead était négligeable par rapport au temps d’I/O
réel.)

J’ai utilisé la commande WrkDskSts (Work with Disk Status) pour observer le nombre
de demandes de transfert et la taille des données lues sur disque et transférées
en mémoire. La commande WrkDskSts est un moyen simple pour examiner l’activité
disque sans recourir au produit de programme sous licence AS/400 Performance Tools.
Les résultats sont suffisamment précis pour juger de l’effet des divers paramètres
de configuration, par exemple, comment le paramètre NbrRcds de la commande OvrDbf
(Override with Database File) influence la taille moyenne de transfert.