Notre application est actuellement utilisée par 1 300 utilisateurs et nous prévoyons 700 utilisateurs supplémentaires.
Pourriez-vous nous conseiller sur les ressources à prévoir pour absorber cette charge supplémentaire ?
Notre application supporte difficilement la charge actuelle.
Nous envisageons de mettre en place un troisième serveur applicatif, faudrait-il également prévoir l’augmentation des ressources existantes ?
Merci.
Technical information
–
Situation actuelle :
2 serveurs applicatifs : 16 cœurs, 32 Go de RAM
1 serveur de base de données : 16 cœurs, 32 Go de RAM
1 serveur de répartition de la charge : 4 cœurs, 4 Go de RAM
[JavaVM]
Version=11.0.17
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=11.0.17+8-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=15424975
HeapSize=20971520
HeapMaxSize=20971520
TotalFreeSize=15424975
Il n’y a pas de sizing “standard” avec Simplicité, tout dépend totalement des caractéristiques métier de votre application et de ce que font les utilisateurs.
Pour sizer la mémoire des serveurs (serveur de base de données et serveur applicatif) vis à vis du nombre utilisateurs il faut déterminer le nombre de sessions utilisateurs simultanés (en régime établi et en pic) et les objets métier utilisés par ces utilisateurs, la taille de ces objets, ex: un objet à 10 attributs dont 5 visible en liste consommera moins de mémoire qu’un objet à 100 attributs, dont 50 visibles en liste), etc.
Pour sizer le CPU des serveurs vis à vis du nombre d’utilisateurs il faut s’intéresser au profil d’usage des utilisateurs, ex: un utilisateur qui n’affiche une liste puis un formulaire en consultation qu’une fois toutes les 5 minutes consommera moins de CPU qu’un utilisateur qui utilise l’application pour faire des mises à jour toutes les 30 secondes en déclenchant des calculs importants ou en affichant de gros tableaux croisés toutes les minutes, etc.
Bref, la meilleure stratégie de sizing consiste toujours à bencher votre infrastructure en executant votre application métier sur des scenarii utilisateurs réalistes et représentatifs de l’activité effective des différents profils utilisateurs.
Si vous travaillez avec un intégrateur, je vous recommande de vous rapprocher de lui pour faire ces opérations de sizing adaptés à votre cas particulier.
Indépendamment du sujet de sizing votre health check indique une revision de Simplicité 5.3.40. Pour information celle-ci date de début juin 2024 et est aujourd’hui en retard d’une quinzaine de révisions (et d’un peu plus de 200 commits) par rapport à la dernière révision de maintenance long terme de la version 5 : 5.3.54 (cf. la release note)
La version de Tomcat utilisée est elle aussi en retard d’une quinzaine de revisions (9.0.80 vs 9.0.95 actuellement).
Idem pour la JVM 11 (11.0.17 vs 11.0.25) qu’il pourrait aussi être intéressant d’upgrader en 17, voire en 21, si c’est possible.
Sur ces points je vous recommande aussi de vous rapprocher de votre intégrateur pour voir quelle(s) mise(s) à jour peuvent être envisagées à court ou moyen terme.