> Tech > Puissance brute

Puissance brute

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour commencer par un exemple simple, examinons les performances de la commande SetObjAcc (Set Object Access), une fonction système OS/400 qui, à notre avis, est un moyen très efficace pour transférer des données du disque en mémoire. Mesurer les performances de cette commande donne une excellente base pour apprécier les

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.

Figure 1 Déclaration du curseur SQL et instructions Fetch pour l’accès par ordre d’arrivée

Déclaration du curseur
Declare MasterTable Cursor
With Hold
For Select *
From Master
For Fetch only

Instruction Fetch monoligne
Fetch Next
From MasterTable
Into :MasterTbl

Instruction Fetch multiligne
Fetch Next
From MasterTable
For :RowsPerFetch Rows
Into :MasterTblArray

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.

Téléchargez gratuitement cette ressource

Endpoint Security : Guide de Mise en œuvre

Endpoint Security : Guide de Mise en œuvre

Détournement d’applications légitimes, élévation de privilèges, logiciels malveillants furtifs : comment les solutions de Endpoint Security permettent elles de faire face aux nouvelles techniques d'attaques complexes ? Découvrez, dans ce Guide Endpoint Security, les perspectives associées à leur mise en œuvre.

Tech - Par iTPro - Publié le 24 juin 2010