Ces benchmarks démontrent que pour bien régler les I/O d'une base de données, il faut bien comprendre comment DB2 UDB et le langage particulier (RPG ou SQL) traitent les opérations d'I/O. Il faut aussi bien connaître l'environnement dans lequel s'exécutera le job, et notamment la quantité de mémoire disponible, le
niveau de contention mémoire et si les pools de mémoire partagée fonctionnent
en mode *Calc ou *Fixed. Enfin, il faudra probablement faire quelques expériences
pour trouver le paramétrage optimal. Mais les résultats des tests précédents
pourront vous aider à réduire la liste à un nombre raisonnable de choix.
Vous pouvez aussi utiliser ces données pour évaluer la signification des différences
de performances entre RPG et SQL dans le contexte de l’application complète.
Dans certains cas exigeants, vous souhaiterez peut-être la plus grande rapidité
du RPG et, dans d’autres, vous privilégierez le niveau supérieur de fonctionnalités
et de manipulation standard des données du langage SQL. Dans toutes ces décisions,
n’oubliez pas que » les faits démentent l’intuition « . Et désormais vous connaissez
les faits. Paul remercie Dale Webber, de la Division AS/400 d’IBM, pour l’aide
qu’il lui a apportée dans cet article.
Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.
