Performance : x1 x2 …x5..10..20..50…x100 !

Les performances d’une application J2EE deviennent de plus en plus une exigence naturelle quand elle n’est pas contractuelle. Architectes, développeurs, experts DBA doivent collaborer dès le début du projet. Des recherches multicritères, des bases de données de quelques dizaines de Giga deviennent courantes…

Une fois livrée, une nouvelle application J2EE fonctionne très bien avec une fluidité souvent seulement limitée par la bande passante réseau ou internet….mais après quelques jours, semaines et mois de mise en production, elle peut montrer des signes de ralentissement pouvant devenir très gênant et voire bloquant.
L’optimisation de la structure de la base de données devient très vite inévitable, durant des tests de charge et tests IHM (LoadRunner, Jmeter, OpenSTA), on observe via OEM ou la dbconsole (ci dessous), Tkprof pour les experts, l’ensemble de transactions…
Le module performance de la console ORACLE (dbconsole) dresse rapidement les requêtes les plus utilisés et permet d’observer en – de 2 minutes les plans d’exécutions des requêtes à optimiser.

Eviter les FULL SCAN de table par exemple, une simple requête prend quelques millisecondes sur une table de 100 enregistrements alors qu’elle prendra beaucoup plus de temps lorsqu’elle atteindra des milliers, des millions d’enregistrements.
Les tests de charge, aux limites, d’endurance ou encore de stress effectués après un vieillissement accéléré de l’application remontent ces bottlenecks qu’il faudra solutionner avant mise en production.

Améliorer sa base de données : Quelques points à vérifier.

  • Indexation (optimisation des select mais ralenti les insert, delete, update)
  • Statistiques (exécution régulière voire quotidienne)
  • Paramètres internes : SGA, PGA, LOG Buffer, cache…. (Variables aussi importantes que la taille d’une machine virtuelle java JVM)
  • Partitionnement, multithread, Pool JDBC, tablespaces, deadlock, …

Liens vers de bonnes pratiques :

Ce billet résume un retour d’expérience d’une application J2EE dont les performances métiers ont été multiplié par plus de 80 !

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Une réflexion au sujet de « Performance : x1 x2 …x5..10..20..50…x100 ! »

  1. Petit résumé qui fait plaisir a lire : Oui il faut faire des tests à volumétrie cible avant la mise en production ! 🙂
    Et gardez bien en mémoire qu'un deadlock est un problème de conception applicative, ou la réflexion (loin d'être facile) sur l'enchainement des accès concurents n'a pas été portée jusqu'au bout. Améliorer les performances de la base de données ne supprimera jamais un deadlock, mais peut reduire sa fréquence d'apparition (jusqu'à la rendre quasi nulle).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*