> Tech > Optimiser les performances batch de l’AS/400

Optimiser les performances batch de l’AS/400

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

par Rick Turner
Structurer les applications et optimiser l'environnement d'exécution batch pour une efficacité maximale Au cours des derniers mois, je suis intervenu sur certains sites AS/400 qui devaient multiplier par cinq voire même 50 leur charge de travail batch en back office. Le premier cas concernait une application de paie devant traiter 500.000 employés alors qu'elle en traitait 100.000 auparavant. Pour le deuxième cas, il s'agissait d'une banque qui, par suite d'un regroupement, devait passer de 600.000 comptes à  30 millions. Dans les deux cas, le traitement des nouvelles charges de travail devait être effectué dans le même laps de temps qu'auparavant.

Pour atteindre leurs objectifs au niveau des temps de traitement, ces clients devaient modifier leurs programmes applicatifs pour qu'ils exploitent au mieux la puissance de l'AS/400. La méthode consistait à  utiliser plusieurs copies des jobs de traitement, chacune travaillant sur des parties distinctes des données en entrée, pour effectuer davantage de travaux dans le même temps et en mettant davantage la CPU à  contribution. C'est tout à  fait possible puisque l'AS/400 traite parfaitement plusieurs jobs à  la fois.

Pourtant, malgré les modifications, les utilisateurs ne parvenaient pas toujours à  pousser le débit de leurs applications batch jusqu'aux limites des ressources du système. Et donc, ils ne pouvaient pas tenir les délais alloués. D'où leur question, "Comment effectuer beaucoup plus de travail dans un laps de temps identique?"

On peut apporter deux éléments de réponse : Utiliser au maximum la CPU et utiliser le disque jusqu'aux plus hautes valeurs de seuil recommandées. Cet article explique quelques méthodes de traitement susceptibles d'améliorer le débit d'un travail en batch. Je propose quelques idées générales sur la manière de structurer une application et de créer un environnement d'exécution optimal (pour le matériel et le logiciel), afin de réaliser le maximum de travail utile dans le minimum de temps.

Optimiser les performances batch de l’AS/400

Qu’est-ce que le traitement batch ?

De nombreux « experts » parmi les spécialistes de l’informatique semblent ignorer
que l’AS/400 effectue parfaitement bien deux types de traitements. Dans le scénario
classique, de gros volumes de traitements brefs et rapides sont associés à  l’entrée
provenant de clients 5250 ou d’autres unités Client/Serveur. Un scénario similaire
consiste à  traiter des jobs pilotés par messages qui prennent en compte une demande
d’entrée à  la fois.

Le second (et moins connu) type de traitement fort bien accompli par l’AS/400
est le batch, ou traitement par lots. Certains gestionnaires croient encore qu’il
est préférable de confier de gros volumes de travail batch à  de puissants mainframes
isolés (dans leur « maison de verre »). Mais en réalité, l’AS/400 peut faire beaucoup
de choses pour un coût unitaire bien inférieur à  certains gros systèmes.

L’OS/400 définit plusieurs types de jobs, parmi lesquels on trouve le type B (batch)
et le type I (interactif). Le type I s’applique aux jobs qui travaillent avec
des données en entrée émanant d’une station de travail 5250 ou d’un autre équipement
émulant un flot de données 5250. La commande WRKACTJOB (Work with Active Jobs)
fait apparaître le type d’un job actif.

La distinction entre les deux types de jobs (B et I) permet d’acheminer une unité
de travail vers le sous-système approprié (QBATCH pour batch, QINTER pour interactif,
par exemple). De plus, quand un job de type I utilise la CPU, la consommation
des cycles processeur diminue la capacité de travail interactif de la machine.
(Cette valeur est appelée ICPW (Interactive Commercial Processing Workload) rating).
En revanche, quand un job de type B utilise la CPU, la consommation des cycles
processeur diminue la capacité totale de la machine. (Cette valeur est appelée
PCPW (Processor Commercial Processing Workload) rating).

N’importe quel type de job peut traiter des données de la base de données ou d’autres
types de données. Pour traiter des données de la base de données, le job peut
lire un enregistrement, le modifier, puis le réécrire dans le fichier, lire certaines
données, les traiter, puis réécrire un nouvel enregistrement dans le fichier d’où
il a lu les données, ou encore se procurer de nouvelles données et les ajouter
à  un fichier existant ou nouveau. Pour moi, il s’agit avant tout d’améliorer les
performances des jobs batch qui traitent des données issues de la base de données
(lecture, mise à  jour, ajout, suppression, par exemple) sur un seul système (ou
dans une partition unique sur un système à  partitionnement logique (LPAR)).

Analyser les performances de l’application

Pour améliorer les performances d’une application, il faut pouvoir les mesurer
dans un environnement contrôlé, avant et après modification. Il est donc impératif
d’avoir un environnement d’exécution reproductible, un jeu de données en entrée,
et une sauvegarde de ces données.

Avant chaque session mesurée, il faut restaurer les données en entrée sur disque
et enlever les éventuelles données résiduelles de la mémoire centrale, pour ne
pas influencer le nombre d’opérations disque physiques. Pour retirer les fichiers
base données de la mémoire centrale, on utilise la commande SETOBJACC (Set Object
Access) en indiquant le nom du fichier et l’option *PURGE.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro.fr - Publié le 24 juin 2010