[Nantes JUG] – Gestion des performances des applications Java/JEE

C'est une salle quasi pleine qui a accueilli ce jeudi 20 mai, au JUG de Nantes, Stéphane Routhiau, pour nous sensibiliser aux problématiques de performances avec Java/JEE. Après quelques années passées au sein de SSII classiques, cet indépendant a monté sa société de conseil en architecture des SI et Optimisation des performances, Routhiau Conseil.

Même si le premier signe d'un manque de performance vient souvent des utilisateurs eux-mêmes, un audit s'appuie sur des données techniques. Les sources de données peuvent être issues du monitoring d'un serveur, de l'étude des temps de réponses, ou encore de l'analyse des logs applicatifs.

Quelles peuvent être les conséquences d'un manque de performances ?

  • Aspects techniques :
    • manque de fiabilité : erreurs aléatoires difficilement reproductibles ;
    • problèmes de vieillissement, avec pour conséquences une dégradation progressive des performances, des fuites mémoires, ou même parfois des crash de JVM ou de serveurs ;
    • manque de sécurité : vulnérabilité plus importante aux attaques DOS ou DDOS ;
    • montée en charge inefficace ;
    • blocages intempestifs qui rendent impossible l'utilisation de la totalité des ressources disponibles ;
    • mise à l'échelle impossible : malgré un pourcentage d'utilisation CPU proche de 0 sur l'ensemble des serveurs, montée en charge inefficace ;
    • des phénomènes inattendus : l'application "tombe en marche", puis tombe de nouveau en panne.
  • Aspects économiques :
    • l'incohérence des données provoque un retour arrière difficile et coûteux ;
    • la qualité de service n'est pas au rendez-vous ;
    • financièrement, on voit un surcoût en terme de matériels, de licences et de maintenance ;
    • mauvaise image de l'entreprise vis-à-vis de ses clients et prestataires.

Face à cela, quels sont les différents axes de solutions possibles ?

AXE 1 : Mise à l'échelle

  • Objectif : faire évoluer l'architecture physique pour améliorer la scalabilité.
  • Cela passe souvent par l'ajout de nouveau matériel.
  • Avantages :
    • load balancing, qui permet de distribuer la charge entre plusieurs processus ou machines ;
    • clustering complet.
  • Points d'attention
    • Ce n'est pas parce qu'un serveur est scalable que l'application qui tourne dessus l'est également!
    • Ces technologies ont un coût croissant, d'où la question du retour sur investissement.

AXE 2 : Architectures physique et logicielle

  • Exemples de problèmes rencontrés :
    • Mise en œuvre d'une architecture SOA sur une architecture physique pas adaptée.
    • Utilisation de caches difficile voir impossible.
  • Préconisations :
    • Séparer au maximum les aspects techniques des aspects métiers.
    • Adapter le périmètre technique aux contraintes de performances.
    • Utiliser des caches.

AXE 3 : La conception technique

  • Objectifs :
    • Respecter la continuité de l'architecture.
    • Garantir la transparence des aspects techniques.
    • Permettre la réutilisabilité des éléments techniques.
  • Problèmes rencontrés :
    • Synchronisation abusive due à un "multithreading maison".
    • Manque de patterns.
    • Pas de supervision (type JMX) du déroulement des batchs.
    • Recopie de modèles à outrance.
  • Préconisations :
    • Patterns adaptés aux technologies du projet.
    • Utilisation adaptée des technologies.
    • Intégrer efficacement les frameworks.
    • Trouver le bon compromis entre les accès concurrents et la synchronisation.

AXE 4 : Le développement

Cet axe est celui qui parlera peut-être le plus aux développeurs, mais il n'est que la finalisation de toute l'étude en amont représentée par les axes précédents.

  • Objectifs :
    • Maximiser l'exécution du code métier et diminuer le coût du code de l'infrastructure : en général, sur 100 lignes de codes exécutées, seules 5 sont du domaine métier, contre 95 du domaine technique !
    • Faciliter le travail de la JVM et du serveur d'application.
  • Préconisations :
    • Guider les développements par l'architecture et la conception.
    • Automatiser la revue de code, à l'aide d'outils comme PMD ou FindBugs.
    • Le code simple est performant.
  • "Worst practices" :
    • Code "spaghetti" illisible "orienté perf".
    • Utilisation de session web comme cache applicatif.
    • Pas de protection des arguments de traces applicatives.
    • Manipulations de chaînes.
    • Synchronisation systématique.
    • Multithreading "maison".
    • System.gc() !!

AXE 5 : Déploiement

  • Objectif : configurer de manière adaptée la JVM, le serveur d'applications et les autres mécanismes connexes utilisés en fonction de l'application et des performances attendues.
  • JVM
    • Importance de la JVM :
      • Compilateur optimisant.
      • Algorithme de Garbage Collection.
      • Gestion des threads.
      • Gestion des verrous.
    • Configuration de la JVM :
      • Client vs Server.
        • Client : pour des applis sur poste client avec une interface graphique Swing et sans charge concurrente.
        • Server : pour un serveur d'application, avec une meilleure gestion de la concurrence et du multithreading.
      • Réglage du Garbage Collector. Principales familles : MonoThreading / MultiThreading / Concurrent. A noter que des combinaisons sont possibles.
  • Serveur d'applications.
    • Critères de choix :
      • Haute disponibilité
      • Facteur de mise à l'échelle
      • Performances attendues
      • Type d'application à déployer
    • Réglages à adapter :
      • Files d'exécution (threads)
      • Cycle de vie des composants
      • Gestion des transactions
  • Mécanismes connexes : accès à la base de données, cache, gestion des sessions utilisateur, protocoles de communications entre les composants...

Comment intégrer cette problématique des performances dans la vie du projet ?

On doit pour cela effectuer des tests et des optimisations de charge lorsque l'application est assainie (la plupart des bugs sont corrigés).

  • Objectif : déterminer "l'optimum de parallélisme" grâce à une étude de montée en charge.

PerfJava_EtudeMonteeCharge

  • Sur quoi tester ? De préférence, sur les 20% du code dans lequel on passe 80% du temps (règle des "80-20").
  • A quelles occasions tester ?
    • Audit "au fur et à mesure" : une bonne pratique serait de câbler ces tests de montée en charge au mécanisme d'intégration continue.
      • Objectif : Minimiser les coûts, délais et risques.
      • Avantages : détection rapide des erreurs, qualification du code "au fil de l'eau", tests de charge réguliers...
    • Audits plus ponctuels et ciblés.
      • Objectifs :
        • Donner un ensemble de préconisations.
        • Les attentes doivent nécessairement être ciblées.
      • Proposer des axes d'amélioration à court, moyen, et long termes.

Résultat : chaque préconisation est associée à une priorité, un risque, une charge, et une estimation des gains.

Il faut cependant noter que les tests effectués dépendent également des performances de rendu du navigateur utilisé.

Ce que nous avons retenu de cette présentation :

  • Les outils de monitoring à utiliser sont le plus souvent proposés avec l'élément à tester (JVM, BDD, Serveur applicatif).
  • L'architecture y est pour beaucoup dans les problématiques de performance : bien cibler les contraintes applicatives et adapter l'architecture physique et logicielle est cruciale.
  • L'optimisation des caches va souvent de paire avec l'amélioration des performances.
  • Il n'y a pas de JVM ni de serveur d'application magiques : tout est une question de paramétrage en fonction de l'application et des performances attendues.
  • La complexité croissantes des applications conduit souvent, malheureusement, à la dégradation des performances : il faut donc adapter au fur et à mesure l'architecture physique aux nouvelles contraintes des applications qu'elle supporte.

Laisser un commentaire

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

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.