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 cette ressource
Comment sécuriser une PME avec l’approche par les risques ?
Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.
