His­toire de performance

His­toire de performance

mer 11 décembre 2024 0 Par Ibmiiste

Intro­duc­tion

Le sys­tème IBM i, ancien­ne­ment appe­lé AS/400, est lar­ge­ment recon­nu pour sa robus­tesse et sa fia­bi­li­té dans les envi­ron­ne­ments d’en­tre­prise. Grâce à son archi­tec­ture inté­grée unique, il gère effi­ca­ce­ment les appli­ca­tions à tra­vers le monde. Cepen­dant, pour tirer le meilleur par­ti de cette pla­te­forme, il peut être impor­tant de com­prendre com­ment opti­mi­ser les per­for­mances des pro­grammes RPGLE. Cet article pré­sente une étude des tests de per­for­mance réa­li­sés sur un IBM i, met­tant en lumière l’im­pact de dif­fé­rentes pra­tiques de codage sur les temps d’exécution.

Objec­tif des Tests de Performance

Ces tests ont été réa­li­sés dans le but de com­pa­rer les per­for­mances de dif­fé­rents frag­ments de code RPGLE dans un envi­ron­ne­ment IBM i. L’ob­jec­tif était de déter­mi­ner l’in­fluence de diverses pra­tiques de pro­gram­ma­tion, telles que l’u­ti­li­sa­tion ou non de l’ins­truc­tion INLR, et d’é­va­luer l’ef­fet des niveaux d’op­ti­mi­sa­tion sur les temps d’exé­cu­tion des programmes.

Vue d’ensemble de l’Environnement de Test

Les tests ont été effec­tués sur un sys­tème IBM i de gamme moyenne. Le sys­tème exé­cu­tait la der­nière ver­sion du sys­tème d’ex­ploi­ta­tion IBM i(7.5), avec le lan­gage RPGLE pour les scripts de test. Deux frag­ments de code dis­tincts ont été uti­li­sés, l’un appe­lant l’autre, pour mesu­rer les per­for­mances en fonc­tion des opti­mi­sa­tions appli­quées et des struc­tures de pro­gramme employées.

Métho­do­lo­gie des Tests

Pour garan­tir la pré­ci­sion des résul­tats, chaque test a été exé­cu­té plu­sieurs fois dans les mêmes condi­tions. Le prin­ci­pal indi­ca­teur de per­for­mance com­pa­ré était le temps CPU, mesu­ré en UC(s) (uni­tés de CPU). Les scé­na­rios éva­lués com­pre­naient des appels de pro­grammes stan­dards avec *INLR à *ON, de pro­gramme sans ins­truc­tion INLR, de sous-pro­cé­dure dans un module de pro­gramme mul­ti­mo­dule et de sous-pro­cé­dure conte­nu dans un Pro­gramme de Ser­vice (SRVPGM).

Ana­lyse des Frag­ments de Code

Le pre­mier frag­ment de code consis­tait en une boucle simple dans un pro­gramme RPGLE, appe­lant une fonc­tion qui cal­cule la cir­con­fé­rence d’un cercle. Voi­ci un aper­çu du code :

**FREE
ctl-opt main(LOOPS) Dftactgrp(*no) actgrp('PERFORM');
Dcl-pr diametreCercle extpgm('DIAMCERCLE');
    rayon float(4) const;
end-pr;

dcl-proc LOOPS;
Dcl-pi *n extpgm('LOOPS');
End-pi;
    dcl-s counter int(10);
    *inlr = *on;
    for counter = 1 to 10000000;
        diametreCercle(6371);
    endfor;
    return;
end-proc;

L’op­ti­mi­sa­tion de cet aspect peut avoir un impact signi­fi­ca­tif sur les per­for­mances, comme nous le ver­rons dans les résultats.

Le deuxième frag­ment de code se concentre sur le cal­cul de la cir­con­fé­rence dans une pro­cé­dure séparée.

**FREE
ctl-opt Main(diametreCercle) dftactgrp(*no) actgrp('PERFORM');

dcl-proc diametreCercle;
    dcl-pi *n extpgm('DIAMCERCLE');
        rayon float(4) const;
    end-pi;
    dcl-s circonference float(4);
    *Inlr = *On;
    circonference = 2 * 3.14159 * rayon;
    return;
end-proc;

Exé­cu­tion

L’ap­pel sera sou­mis avec la com­mande SBMJOB dans les mêmes condi­tions et dont nous pour­rons recueillir un spool où est consi­gné le temps CPU utilisé.

SBMJOB CMD(CALL PGM(LOOPS))
       JOB(PRFSTDLRFL)     
       LOG(4 0 *SECLVL)    
       LOGCLPGM(*YES)      

Métriques de Performance

Les métriques uti­li­sées pour com­pa­rer les per­for­mances incluaient le temps CPU (UC(s)) consom­mé par les dif­fé­rents scé­na­rios. Les niveaux d’op­ti­mi­sa­tion appli­qués étaient :

  • SANS : Aucun niveau d’op­ti­mi­sa­tion spé­ci­fique, géné­ra­le­ment acti­vée par défaut.
  • BASIC : Opti­mi­sa­tion de base.
  • FULL : Opti­mi­sa­tion com­plète, visant à maxi­mi­ser la performance.

Les tests ont cou­vert quatre types d’exécution : l’appel

  • de pro­gramme stan­dard avec l’in­di­ca­teur LR à *ON,
  • de pro­grammes sans INLR(*OFF),
  • d’un pro­gramme multimodule, 
  • et d’un Pro­gramme uti­li­sant une sous-pro­cé­dure incluse dans un pro­gramme de Ser­vice (SRVPGM).

Résul­tats des Tests : Temps d’Exécution

Les résul­tats obte­nus lors des tests sont les suivants :

Per­for­manceAppel de pro­grammePro­gramme sans INLRMul­ti­mo­dulesSRVPGM
SANS opti­mi­sa­tion6,155 UC(s)6,010 UC(s)0,490 UC(s)0,505 UC(s)
BASIC opti­mi­sa­tion5,633 UC(s)5,850 UC(s)0,341 UC(s)0,367 UC(s)
FULL opti­mi­sa­tion5,479 UC(s)5,294 UC(s)0,108 UC(s)0,147 UC(s)

Nous pou­vons noter une réelle dif­fé­rence entre les appels de pro­grammes et les appels ILE par copy(programme mul­ti­mo­dule) ou par référence(Programme de ser­vice). L’optimisation com­plète a réduit les temps d’exécution, en par­ti­cu­lier pour le pro­gramme mul­ti­mo­dule et l’u­ti­li­sa­tion d’un pro­gramme de Service.

Impact des Niveaux d’Optimisation

Les dif­fé­rents niveaux d’optimisation affectent le com­por­te­ment du code com­pi­lé. Le niveau FULL, par exemple, se tra­duit par des gains de per­for­mance substantiels.

Impact de INLR sur la Performance

L’ins­truc­tion INLR (*INLR = *ON) joue un rôle dans la libé­ra­tion des res­sources à la fin de l’exé­cu­tion d’un pro­gramme RPG. En désac­ti­vant cette ins­truc­tion, le pro­gramme évite la réini­tia­li­sa­tion com­plète des variables et des états, ce qui peut amé­lio­rer les per­for­mances. Les tests montrent que l’op­ti­mi­sa­tion FULL com­bi­née à la sup­pres­sion de *INLR peut légè­re­ment réduire le temps CPU.

Voi­ci les sources uti­li­sés pour ce scé­na­rio, com­pi­lés avec la com­mande CRTBNDRPG afin de créer 2 pro­grammes distincts.

  • Avec *INLR à *ON
**FREE
ctl-opt main(LOOPS) Dftactgrp(*no) actgrp('PERFORM');
Dcl-pr fonction extpgm('FONCTION');
    rayon float(4) const;
end-pr;

dcl-proc LOOPS;
Dcl-pi *n extpgm('LOOPS');
End-pi;
    dcl-s counter int(10);
    *inlr = *on;
    for counter = 1 to 10000000;
        fonction(6371);
    endfor;
    return;
end-proc;
**FREE
ctl-opt Main(diametreCercle) dftactgrp(*no) actgrp('PERFORM');

dcl-proc diametreCercle;
    dcl-pi *n extpgm('DIAMCERCLE');
        rayon float(4) const;
    end-pi;
    dcl-s circonference float(4);
	*inlr = *on;
    circonference = 2 * 3.14159 * rayon;
    return;
end-proc;
  • Sans *INLR à *ON
**FREE
ctl-opt main(LOOPS) Dftactgrp(*no) actgrp('PERFORM');
Dcl-pr diametreCercle extpgm('DIAMCERCLE');
    rayon float(4) const;
end-pr;

dcl-proc LOOPS;
Dcl-pi *n extpgm('LOOPS');
End-pi;
    dcl-s counter int(10);
    
    for counter = 1 to 10000000;
        diametreCercle(6371);
    endfor;
    return;
end-proc;
**FREE
ctl-opt Main(diametreCercle) dftactgrp(*no) actgrp('PERFORM');

dcl-proc diametreCercle;
    dcl-pi *n extpgm('DIAMCERCLE');
        rayon float(4) const;
    end-pi;
    dcl-s circonference float(4);
    circonference = 2 * 3.14159 * rayon;
    return;
end-proc;

Spools

Avec LR à *ON

Sans opti­mi­sa­tion
Opti­mi­sa­tion BASIC
Opti­mi­sa­tion FULL

Avec *INLR à *OFF

Sans opti­mi­sa­tion
Opti­mi­sa­tion *BASIC
Opti­mi­sa­tion *FULL

Pro­grammes Mul­ti­mo­dules et Performance

Les pro­grammes mul­ti­mo­dules per­mettent de divi­ser le code en plu­sieurs modules, ce qui amé­liore la modu­la­ri­té et peut éga­le­ment affec­ter les per­for­mances. Les tests montrent que ces pro­grammes peuvent béné­fi­cier d’une opti­mi­sa­tion complète.

Dans notre cas, les 2 sources seront com­pi­lés avec CRTMODRPG pour obte­nir 2 modules que nous com­bi­ne­rons en un seul pro­gramme avec CRTPGM.

**FREE
ctl-opt main(LOOPS);
Dcl-pr diametreCercle extproc('DIAMCERCLE');
    rayon float(4) const;
end-pr;

dcl-proc LOOPS;
Dcl-pi *n extpgm('LOOPS');
End-pi;
    dcl-s counter int(10);
    *inlr = *on;
    for counter = 1 to 10000000;
        diametreCercle(6371);
    endfor;
    return;
end-proc;
**FREE
ctl-opt nomain;

dcl-proc diametreCercle export;
    dcl-pi *n extproc('DIAMCERCLE');
        rayon float(4) const;
    end-pi;
    dcl-s circonference float(4);
    circonference = 2 * 3.14159 * rayon;
    return;
end-proc;

Spools

Sans opti­mi­sa­tion

Opti­mi­sa­tion BASIC

Opti­mi­sa­tion FULL

Per­for­mance des Pro­grammes de Ser­vice (SRVPGM)

Les Pro­grammes de Ser­vice sont une agré­ga­tion de sous-pro­cé­dures qui peuvent être appe­lées par réfé­rence. Ces tests ont révé­lé que les SRVPGM opti­mi­sés offrent des per­for­mances supé­rieures, notam­ment grâce à la réduc­tion du temps d’appel.

Le source DIAMCERCLE sera uti­li­sé pour créer(commande CRTMODRPG) le module et celui-si sera inté­gré au pro­gramme de ser­vice LOOPSSRV(Commande CRTSRVPGM).

**FREE
ctl-opt nomain;

dcl-proc diametreCercle export;
    dcl-pi *n;
        rayon float(4) const;
    end-pi;
    dcl-s circonference float(4);
    
	circonference = 2 * 3.14159 * rayon;
    
	return;
end-proc;

Le source LOOPS sera com­pi­lé pour avoir un module.

**FREE
ctl-opt main(LOOPS);
Dcl-pr diametreCercle;
    rayon float(4) const;
end-pr;

dcl-proc LOOPS;
Dcl-pi *n extpgm('LOOPS');
End-pi;
    dcl-s counter int(10);
    *inlr = *on;
    for counter = 1 to 10000000;
        diametreCercle(6371);
    endfor;
    return;
end-proc;

L’é­tape sui­vant est de créer le pro­gramme de ser­vice LOOPSSRV.

CRTSRVPGM SRVPGM(LOOPSSRV) MODULE(DIAMCERCLE) ACTGRP(*CALLER) EXPORT(*ALL) TEXT('Calcul diam cercle')

Et enfin le programme.

CRTPGM PGM(LOOPS) MODULE(LOOPS) ACTGRP(PERFORM) BNDSRVPGM(LOOPSSRV)  

Spools

Sans opti­mi­sa­tion

Opti­mi­sa­tion BASIC

Opti­mi­sa­tion FULL

Impli­ca­tions Pra­tiques pour les Développeurs

Les résul­tats de ces tests four­nissent des indi­ca­tions pré­cieuses pour les déve­lop­peurs sou­hai­tant opti­mi­ser leurs appli­ca­tions sur IBM i. En tenant compte des effets de l’INLR, en choi­sis­sant le niveau d’op­ti­mi­sa­tion appro­prié et en des types d’ap­pel, il est pos­sible de réduire signi­fi­ca­ti­ve­ment les temps d’exécution des programmes.

Recom­man­da­tions pour l’Op­ti­mi­sa­tion d’IBM i

Sur la base des tests, il est recom­man­dé d’u­ti­li­ser le niveau d’op­ti­mi­sa­tion FULL pour les pro­grammes cri­tiques, d’en­vi­sa­ger l’u­ti­li­sa­tion de pro­grammes mul­ti­mo­dules ou l’u­sage de pro­gramme de ser­vice pour amé­lio­rer de façon signi­fi­ca­tive les per­for­mances. En plus d’a­mé­lio­rer les per­for­mances du même ordre que les pro­grammes mul­ti­mo­dules, les pro­gramme de ser­vice ajoute une amé­lio­ra­tion de la maintenabilité.

Limites de l’Étude

Bien que ces tests aient four­ni des résul­tats utiles, ils ont été réa­li­sés dans un envi­ron­ne­ment contrô­lé et peuvent ne pas reflé­ter toutes les condi­tions du monde réel. De futures études(fait par d’autres) pour­raient inclure une plus grande varié­té de scé­na­rios pour ren­for­cer les conclusions.

Conclu­sion

L’optimisation des per­for­mances sur IBM i est une tâche com­plexe mais essen­tielle pour assu­rer le bon fonc­tion­ne­ment des appli­ca­tions cri­tiques. Ces tests montrent l’im­por­tance de com­prendre les effets des dif­fé­rentes pra­tiques de codage et des niveaux d’op­ti­mi­sa­tion sur les per­for­mances glo­bales du système.

Nous pou­vons noter que les appels par copie(multimodules) et ceux pas référence(programme de ser­vice) amè­liorent d’un rap­port de 10 les per­for­mances par rap­port à des appels de pro­grammes. D’où l’in­té­rêt de moder­ni­ser vos appli­ca­tions en exploi­tant au mieux les pos­si­bi­li­té qu’offre Ile.

Ques­tions Fré­quem­ment Posées (FAQ)

  1. Qu’est-ce que le sys­tème IBM i ?
    IBM i est une pla­te­forme d’en­tre­prise inté­grée, connue pour sa sta­bi­li­té, sa sécu­ri­té et ses capa­ci­tés de trai­te­ment transactionnel.
  2. Pour­quoi les tests de per­for­mance sont-ils impor­tants sur IBM i ?
    Ils per­mettent d’i­den­ti­fier les gou­lots d’é­tran­gle­ment et d’op­ti­mi­ser l’u­ti­li­sa­tion des res­sources, cru­cial pour les appli­ca­tions critiques.
  3. Qu’est-ce que INLR dans RPGLE, et pour­quoi affecte-t-il les per­for­mances ?
    INLR est une ins­truc­tion qui réini­tia­lise les res­sources à la fin d’un pro­gramme. En la sup­pri­mant, on peut amé­lio­rer très légè­re­ment les per­for­mances en évi­tant des opé­ra­tions de nettoyage.
  4. Que sont les Pro­grammes de Ser­vice dans IBM i ?
    Ce sont des ensembles de sous-pro­cé­dures réuti­li­sables qui peuvent être appe­lés par d’autres pro­grammes, offrant flexi­bi­li­té et per­for­mances améliorées.
  5. Com­ment les niveaux d’op­ti­mi­sa­tion affectent-ils le code RPGLE ?
    Les niveaux d’op­ti­mi­sa­tion modi­fient la façon dont le code est com­pi­lé, influen­çant la vitesse d’exé­cu­tion et l’ef­fi­ca­ci­té des programmes.
  6. Quels sont les avan­tages des pro­grammes mul­ti­mo­dules ?
    Ils per­mettent une meilleure orga­ni­sa­tion du code et peuvent amé­lio­rer les per­for­mances en rédui­sant le temps de com­pi­la­tion et d’exécution.

Res­sources Externes

Pour plus d’in­for­ma­tions, consul­tez la docu­men­ta­tion offi­cielle d’IBM sur l’op­ti­mi­sa­tion des per­for­mances RPGLE et d’autres res­sources tech­niques pertinentes.

Annexes

Les sources pour tes­ter vous-même sont sur Github, les objets sont construites grâce à BOB et Sour­ceor­bit dans Vscode :