Monitoring des performances

[JeanMichelC]

Bonjour,

Nous prévoyons de lancer des tests de performances sur notre instance simplicité.

Est-ce que vous avez une idée de l’impact de l’activation du monitoring sur les performances ? Peut-on le considérer comme négligeable ?

Autre question un peu en marge, j’ai remarqué que des cron de GC dynamique/full se déclenchent régulièrement. Dans le cadre de tirs de performances, leur déclenchement peut-il avoir un effet négatif sur les performances ??

Merci d’avance.

[david (David AZOULAY)]

Lors de tests en charge il est recommandé de désactiver toute supervision = la supervision interne à Simplicité et toute supervision externe, ex: appels réguliers sur /health (ou /ping) ou monitoring JMX.

L’idée est de savoir déjà comment répond l’application quand elle n’est pas perturbée par ce genre de supervision.

Ensuite il peut être intéressant de refaire le même test en charge avec ces différents types supervision pour en mesurer l’effet concret => ça permet de trouver le bon compromis entre niveau/fréquence de supervision et performances.

S’agissant des tâches cron, c’est un peu le même raisonnement => tester d’abord sans, puis avec. Il y a juste les tâches GC sur lesquelles je préfère que @Francois donne son avis.

Sinon de manière plus générale les performances niveau UI ou niveau API (ex: utilisées par des frontends externes) peuvent être radicalement différentes :

• au niveau UI on et dans le cadre de sessions statefull où des synchronize empêchent légitimement de faire des appels identiques/similaires en // (dans un usage UI on ne fait à priori pas plusieurs choses en même temps).
• au niveau API on est dans des appel stateless où il est possible d’utiliser des mécanismes avancés (pooling, caching) permettant de faire massivement des appels identiques/similaires en // y compris via le même user

Juste pour donner un ordre d’idée on a récemment fait des tests en charge API où on a tenu sans pb plusieurs centaines (voire milliers dans certaines conditions) d’appels par seconde avec un user API unique.

Au sein d’une session UI on n’atteindra jamais ce genre de débits. Un test en charge orienté UI doit donc se faire en parallélisant massivement des sessions et en y faisant des choses avec une fréquence d’appel représentative de ce qu’un user fait dans la vraie vie.

[Francois (François Genestin)]

Bonjour,

Quelques précisions :

Sur le monitoring

Il faut forcement observer quelque chose quelque part lorsqu’on fait des tests de charges :

• Quelque chose : cpu, disk, JVM, Tomcat / SGBD… jusqu’à Simplicité back et UI
• Quelque part : depuis un serveur externe à Tomcat/SGBD pour éviter de consommer sa CPU, ou en utilisant des sondes locales pour éviter les I/O distants

Le monitoring Simplicité est basé sur des sondes actives par cron (qui vont faire des snapshots régulièrement de la mémoire, de la JVM, du cache, des sessions, des accès SQL, etc.) et persistantes en base (dans la table m_log utilisée pour afficher les métriques), donc cela perturbera un peu les performances et la volumétrie en base.

Le monitoring front UI peut également être activé pour voir sur le navigateur la répartition interne des temps (call xhr/ajax vs. temps de fabrication du formulaire HTML).

On peut donc tout voir avec d’autres outils/agents, mais il faut nécessairement activer le monitoring Simplicité pour mesurer ses composants internes (cache d’objets métier, accès sql system ou user, type des threads tomcat ou simplicité, …).

Idem sur vos objets/traitements spécifiques, vous pouvez ajouter des traces (en créant des Log Events pour tracer ou persister des informations à analyser dans m_log).

Sur le GC dynamique/full Simplicité :

Cette tache Cron libère la mémoire des instances d’objet plus utilisées (aucun accès CRUD depuis un certain temps sauf cas particulier comme XMLSupervisor pour les imports longs, les sondes AppLogger, les objets singletons system…) :

• Toutes les 15min : vide les données volatiles (pagination courante en mémoire)
• Toutes les 30min : vide les instances inutilisées des sessions

Si une session redemande une instance d’objet après 30 minutes d’inactivité, Simplicité va recloner une instance en mémoire d’après le cache de toutes les définitions d’objet, ce qui reste très rapide).

Si vous faites des tests en charges avec des accès CRUD en masse, les instances d’objet par session ne seront jamais dans ce cas et resteront en mémoire. Il n’y a rien à faire pour des usages UI.

Si vous avez des traitements longs (en calcul sans accès CRUD) sur certaines instances back ou des singletons à ne jamais détruire pour optimiser les perfs vous pouvez désactiver son GC via ObjectDB.enableGC(false) dans le postLoad. L’objet ne sera alors jamais détruit dans la session, il ne sera détruit que sur ObjectDB.destroy() explicite ou au logout / invalidateSession tomcat).