Calcul Charge Abaque Mainframe

Estimez rapidement la charge CPU d’un environnement mainframe à partir du volume transactionnel, du coût CPU unitaire, des traitements batch et d’un coefficient de pointe. Cet abaque interactif vous aide à transformer des hypothèses métier en capacité technique exploitable.

Sortie estimative pour pré-dimensionnement et revue de capacité.

Guide expert du calcul de charge avec abaque mainframe

Le calcul charge abaque mainframe est une méthode de pré-dimensionnement qui transforme des volumes applicatifs en capacité technique lisible. Dans les environnements z/OS, le besoin n’est jamais uniquement lié au nombre d’utilisateurs. Il dépend surtout du coût CPU par transaction, de l’intensité batch, de la variabilité des pointes et de la politique de marge retenue par l’exploitation. Un abaque est utile parce qu’il propose une lecture rapide, stable et comparable d’un scénario de charge, même en phase amont d’un projet lorsque les métriques RMF ou SMF détaillées ne sont pas encore disponibles.

Concrètement, l’idée consiste à ramener toutes les consommations à une même unité, la CPU-seconde par heure, puis à convertir ce besoin en moteurs CPU moyens, en capacité installée théorique et enfin en ordre de grandeur MIPS ou MSU. Cette approche n’a pas vocation à remplacer une campagne de mesure de production. En revanche, elle permet de répondre vite à des questions critiques : combien de réserve faut-il pour un nouveau lot de flux bancaires, quelle hausse de TPS un front digital peut-il absorber, ou encore quel est l’impact d’une hausse batch en fin de mois.

Pourquoi utiliser un abaque plutôt qu’une simple règle de trois

Beaucoup d’estimations échouent parce qu’elles prennent une moyenne brute et oublient les effets de pointe. Un mainframe supporte généralement plusieurs types de charges à la fois : transactions CICS, appels DB2, travaux batch, traitements de clôture, réplication, sécurité, et parfois une couche d’intégration événementielle. Une règle de trois sur le seul nombre de transactions sous-estime presque toujours la consommation réelle. L’abaque ajoute des correctifs structurants :

• un coût CPU unitaire par transaction, en millisecondes ;
• une pondération de complexité applicative ;
• une composante batch horaire ;
• un coefficient de pointe pour traduire les pics ;
• un taux cible d’utilisation pour préserver la marge d’exploitation.

Cette construction est compatible avec les principes de modélisation de performance enseignés dans les institutions techniques et académiques, et elle s’inscrit dans une logique de capacity planning prudente. Pour approfondir les notions de mesure, d’ingénierie des systèmes et d’évaluation de performance, vous pouvez consulter des ressources institutionnelles comme le NIST Information Technology Laboratory, le Software Engineering Institute de Carnegie Mellon ou encore les travaux universitaires sur les files d’attente et la performance de calcul à Cornell University.

Les variables qui pilotent réellement la charge mainframe

Pour produire un calcul crédible, il faut distinguer les facteurs de volume et les facteurs de coût. Le volume correspond à ce qui entre dans le système : nombre de transactions, nombre de jobs, fenêtres horaires, croissance saisonnière. Le coût représente ce que chaque unité de travail consomme. Deux applications à 100 TPS ne se ressemblent pas si l’une exécute un simple contrôle de droits et l’autre mobilise plusieurs accès base, du chiffrement, des contrôles inter-applicatifs et des écritures journalières.

1. Transactions par seconde : c’est le flux online moyen observé ou prévu.
2. CPU par transaction : il s’agit de la consommation CPU réelle, pas du temps de réponse wall-clock.
3. Complexité : elle absorbe les écarts liés aux appels DB, au chiffrement, à la compression ou aux couches intermédiaires.
4. Batch horaire : souvent négligé, il constitue pourtant une part essentielle de la charge.
5. Coefficient de pointe : sans lui, le dimensionnement est presque toujours trop optimiste.
6. Utilisation cible : viser 100 % est un anti-pattern, car la production a besoin de réserve.

Une bonne pratique consiste à estimer d’abord la charge moyenne, puis à appliquer un coefficient de pointe distinct pour les heures sensibles : ouverture de service, clôture, reprises après incident, fins de mois, ou campagnes commerciales.

Formule pratique utilisée par le calculateur

Le calculateur ci-dessus applique une formule simple et robuste. D’abord, la charge online horaire est calculée en multipliant les transactions par seconde par le coût CPU unitaire, puis par 3600 secondes. On ajoute ensuite la charge batch, exprimée en jobs par heure multipliés par le CPU moyen de chaque job. Le total est ensuite ajusté par le coefficient de pointe. Enfin, le besoin est converti en moteurs CPU moyens et en capacité installée cible selon le pourcentage d’utilisation retenu.

• Charge online horaire = TPS × CPU ms/transaction × 3600 / 1000
• Charge batch horaire = jobs/heure × CPU minutes/job × 60
• Charge pondérée = (online + batch) × coefficient de pointe
• Moteurs CPU moyens = charge pondérée / 3600
• Capacité installée cible = moteurs moyens / taux d’utilisation cible

La conversion en MIPS ou en MSU reste indicative, car elle dépend de la génération matérielle, du microcode, des licences et du profil applicatif. Néanmoins, elle est très utile pour donner un ordre de grandeur aux études de capacité, aux ateliers d’architecture et aux revues budgétaires.

Tableau comparatif de scénarios de charge

Le tableau suivant illustre trois scénarios calculés selon la méthode de l’abaque. Les valeurs sont volontairement concrètes afin de montrer l’effet combiné des TPS, du batch et de la marge de pointe.

Scénario	TPS	CPU par transaction	Batch par heure	Charge pondérée	Moteurs moyens	Capacité cible à 70 %
Modéré	50	12 ms	4 jobs de 3 min	3 600 CPU-sec/h	1,00	1,43 moteurs
Soutenu	150	18 ms	8 jobs de 6 min	17 010 CPU-sec/h	4,73	6,76 moteurs
Intensif	400	22 ms	12 jobs de 10 min	58 320 CPU-sec/h	16,20	23,14 moteurs à 70 % ou 21,60 moteurs à 75 %

Ces chiffres montrent une réalité importante : lorsque le volume augmente, les marges de sécurité deviennent aussi importantes que la charge moyenne elle-même. Entre le scénario modéré et le scénario intensif, le besoin n’est pas multiplié seulement par le nombre de TPS. L’effet du batch, des pointes et du taux cible d’utilisation amplifie fortement le dimensionnement final.

Repères indicatifs de conversion par génération de machine

Les équipes projet demandent souvent une traduction en langage financier ou capacitaire. C’est là qu’intervient la correspondance indicative entre moteurs CPU, MIPS et MSU. Les valeurs ci-dessous sont volontairement simplifiées pour servir d’abaque de décision rapide. Elles ne remplacent ni les données constructeur ni les mesures de production.

Génération	MIPS indicatifs par moteur	MSU indicatifs par moteur	Usage typique
IBM z13	1 200	180	Socles encore présents dans des patrimoines historiques et environnements très stabilisés
IBM z14	1 350	200	Charges transactionnelles solides avec exigences de chiffrement renforcées
IBM z15	1 500	230	Consolidation, modernisation API et forte cohabitation online plus batch
IBM z16	1 700	260	Environnements à haute densité avec exigences de résilience et d’accélération plus élevées

Comment interpréter correctement le résultat

Un bon résultat d’abaque ne doit jamais être lu comme un chiffre absolu. Il doit être analysé selon trois niveaux. Le premier niveau est la charge moyenne, utile pour comprendre le socle de fonctionnement. Le deuxième niveau est la charge en pointe, essentielle pour la tenue des fenêtres critiques. Le troisième niveau est la capacité installée cible, qui tient compte du pourcentage d’utilisation à ne pas dépasser durablement.

Si votre calcul donne 5 moteurs moyens et 7 moteurs cibles à 70 %, cela ne signifie pas que 5 moteurs suffisent en production. Cela signifie que 5 moteurs seraient saturés sur la base de la charge en pointe retenue, sans marge d’absorption pour les aléas. En exploitation réelle, il faut intégrer la croissance, l’effet des reprises, les campagnes exceptionnelles, les changements de versions et les dégradations de performance transitoires.

Erreurs fréquentes dans les projets de capacity planning mainframe

• Confondre temps de réponse et temps CPU : le temps de réponse inclut des attentes, pas seulement la consommation CPU.
• Oublier le batch : un environnement paraissant calme en journée peut exploser la nuit ou à la clôture.
• Utiliser un seul profil moyen : les heures d’ouverture et les fins de mois exigent souvent un coefficient spécifique.
• Ignorer la complexité applicative : chiffrement, journalisation et appels DB ajoutent une surconsommation non triviale.
• Dimensionner à 90 % ou 100 % : cela réduit dangereusement la résilience opérationnelle.
• Négliger l’évolution des licences : la capacité technique et le coût logiciel ne suivent pas toujours la même pente.

De l’abaque à la mesure réelle en production

L’abaque est particulièrement performant en phase amont, mais une fois le service en exploitation, il faut recaler le modèle avec des données réelles. Sur mainframe, cela passe en général par l’analyse des journaux de mesure, des rapports de performance, des séries horaires et du comportement des workloads sur plusieurs périodes. Le but est d’identifier les écarts entre l’estimation et le réel : coût transactionnel supérieur, batch concurrent plus lourd, pointe plus forte, ou effet de contention sur les sous-systèmes.

Une démarche mature suit souvent cette séquence :

1. estimation amont avec un abaque simple ;
2. dimensionnement initial avec marge ;
3. mise en production et observation structurée ;
4. recalibrage des coûts unitaires ;
5. industrialisation d’un modèle de charge récurrent.

Cette discipline évite les sous-dimensionnements coûteux comme les surcapacités budgétairement lourdes. Dans les secteurs régulés ou critiques, la capacité ne se pense pas seulement en économie d’infrastructure, mais aussi en continuité de service.

Quand faut-il augmenter le coefficient de pointe

Il est prudent d’augmenter le coefficient de pointe lorsque l’activité n’est pas régulière, quand les flux sont pilotés par des événements externes ou quand un lot de traitements se superpose à l’activité online. Les situations typiques sont les suivantes :

• paiements, virements ou traitements de masse à heure fixe ;
• interfaces partenaires qui envoient en rafales ;
• réouverture après incident ou reprise applicative ;
• clôtures mensuelles, fiscales ou réglementaires ;
• lancement d’une campagne marketing ou d’une opération commerciale.

Dans un environnement très stable, un coefficient de 1,15 à 1,25 peut suffire. Dans un système exposé à des rafales, 1,30 à 1,50 est plus réaliste. La valeur pertinente vient idéalement de l’historique opérationnel.

FAQ rapide sur le calcul charge abaque mainframe

Le calculateur remplace-t-il un benchmark ? Non. Il fournit une estimation structurée pour cadrer un projet ou challenger un ordre de grandeur.

Pourquoi afficher des MIPS et des MSU ? Parce que ces unités parlent à la fois aux équipes techniques, aux achats et à la gouvernance financière.

Peut-on l’utiliser pour un projet de modernisation API ? Oui, surtout si vous savez estimer le coût CPU moyen de chaque appel et les pointes de trafic prévues.

Le batch doit-il être saisi en temps horloge ? Non. Il faut saisir un temps CPU moyen par job, sans quoi la projection sera gonflée artificiellement.

En résumé, un bon calcul charge abaque mainframe ne se limite pas à une formule. C’est une méthode de lecture de la charge qui relie les besoins métier, la performance applicative et la capacité d’exploitation. Utilisez l’outil ci-dessus comme base de dialogue entre architecture, production, études et finance, puis validez toujours les hypothèses avec des mesures réelles dès que les premières séries d’usage sont disponibles.