Aidez-vous des résultats de nos tests pour accroître la vitesse et de l'efficacité de vos applications.Qu'il s'agisse de développer de nouvelles "e-applications" ou d'améliorer d'anciennes "t-applications " (applications traditionnelles), les performances de la base de données est souvent le facteur prépondérant dans la rapidité du logiciel. La satisfaction de la direction et des clients est proportionnelle à la rapidité d'obtention des données. Avec DB2 Universal Database for AS/400 (DB2 UDB), on peut améliorer considérablement les performances applicatives (éventuellement en multipliant plusieurs fois le débit de l'application non optimisée) en choisissant judicieusement la méthode de mise en œuvre et de configuration.
La satisfaction de la direction et des clients est proportionnelle à la rapidité d'obtention des données
Pour obtenir des données concrètes à l'appui de ces types de décisions, j'ai effectué de nombreux benchmarks en utilisant les versions V4R4 de RPG IV et SQL. Certaines constatations sont étonnantes et mettent à nu la manière dont ces langages et DB2 UDB pratiquent l'accès aux bases de données.
Après avoir étudié ces résultats et en avoir discuté avec les IBMers de Rochester, j'ai conclu que les seuls manuels AS/400 ne sont pas suffisants pour optimiser les performances des bases de données. Tandis qu'avec les données et les analyses comparatives de cet article, vous pourrez pousser vos applications dans leurs derniers retranchements. Et aussi comparer les performances des I/O intégrées et du SQL imbriqué dans le RPG IV. (Si vous découvrez le coding SQL, voyez l'encadré " Quelques canevas SQL pour programmeurs RPG", qui fournit des information sur un article en ligne démontrant les techniques de coding SQL/400 pour programmeurs RPG.)
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
*Base 26,5 Mo
*Interact 225 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) +
ObjType(*File) +
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.
Téléchargez cette ressource
Travail à distance – Guide IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- AI Speech double toutes vos vidéos !
- Finance : l’IA générative plébiscitée pour les décisions stratégiques
- Cybersécurité : les comportements à risque des collaborateurs
- Prédictions 2025 : voici comment l’intelligence artificielle va redéfinir la sécurité de 3 façons
- Top 5 des technologies à suivre en 2025 et au-delà !
