Comment bien concevoir vos applications

y aura beaucoup plus d’activité de journalisation que si le fichier est ouvert une fois puis fermé seulement après que toute l’activité le concernant ait eu lieu.

Le contrôle d’engagement influence aussi la performance du journal. « Sans cache journal, si vous n’utilisez pas le contrôle d’engagement, chaque fois que l’application effectue une mise à jour, une insertion, ou une suppression d’enregistrement de la base de données, elle doit attendre que l’entrée journal se termine, » explique Vriezen. « Donc, si j’ai une application Batch qui va mettre à jour deux millions de lignes, il nous faudra attendre deux millions d’écritures disque. »

Le cache journal peut atténuer ce problème parce que, avec lui, vous faites la première mise à jour, il va dans la mémoire système et le système revient immédiatement vers vous.

« Il bâtit le cache jusqu’à un certain seuil puis il fait une écriture disque unique pour couvrir les nombreux enregistrements que vous vouliez envoyer au journal, ce qui donne un bien meilleur rapport entre les entrées du journal et les I/O, » explique Vriezen. « C’est particulièrement important du côté cible d’un scénario haute disponibilité parce que le côté cible à beaucoup moins de jobs qui écrivent des entrées de journal et donc on tend à obtenir beaucoup plus d’ I/O synchrones l’une après l’autre. »

Le contrôle d’engagement lui-même est une forme de cache de facto parce que les entrées de journal sont généralement regroupées en lots et écrites seulement au moment de l’engagement.

Vriezen conseille aussi aux développeurs de considérer l’utilisation de soft commits – qui requièrent l’utilisation du cache journal – lorsqu’ils utilisent le contrôle d’engagement. Vriezen explique qu’avec des soft commits, vous dites en quelque sorte au système, « Oui, je sais, vous êtes censé écrire les données sur disque quand vous faites l’engagement, mais, pour ce job, ne vous souciez pas de l’écrire sur disque, parce que si cette application batch échoue, je vais revenir en arrière, restaurer le fichier tel qu’il était et réexécuter le job. »

Et il ajoute, « Soft commit dit que même les commits ne sont pas écrits sur disque. »

Quand l’option cache est activée, les soft commits sont mis en oeuvre en réglant la variable d’environnement commitment durability (QIBM_TN_COMMIT_DURABLE) sur « No ». Et ce, pour tout le système ou pour un job particulier.

Restez à jour

Les nouvelles releases du système d’exploitation améliorent souvent la performance de la journalisation. Et l’IBM i 6.1 n’a pas fait exception. En restant à jour, vous pouvez glaner quelques avantages sans entreprendre des travaux d’amélioration de performance de journalisation, simplement par la mise à niveau de l’ IBM i.

« Nous nous sommes employés à réordonner le code pour réduire la taille et raccourcir le chemin, » explique Owen. « Nous avons aussi amélioré la performance par des tampons horodateurs. Par exemple, sur une IPL propre nous avons essayé d’envoyer sur le disque le maximum d’objets avec des changements importants. De sorte que, quand vous faites un IPL ou que vous mettez votre ASP indépendant sur vary-on, le journal a beaucoup moins à faire pour récupérer les objets. »

En réalité, régler la journalisation pour améliorer la performance n’est pas si difficile pour des professionnels IBM i chevronnés, mais cela demande un peu de travail et un peu de connaissance. Les IBM Redbooks et les Redbook Technotes sont une excellente source de connaissance détaillée et à jour de la journalisation. Vous pouvez trouver les Redbooks de journalisation et lesTechnotes associées sur le site d’IBM. Au-delà de cet article, vous devriez sans tarder acquérir les tout derniers Redbooks et Technotes pour votre version d’IBM i.