Impacts du fonctionnement de Planisware 5 sur le sizing des serveurs applicatifs
Introduction
Introduction
Afin de gérer au mieux les performances d’une application sous Planisware 5 le dimensionnement des machines est un élément primordial. En effet le fonctionnement du progiciel Planisware induit des contraintes spécifiques en termes :
→ de mémoire vive (RAM)
→ de nombre de coeurs
→ de performance des CPU (type et fréquence)
Il est possible (voire vivement recommandé) de demander à Planisware une étude de sizing afin de déterminer au mieux les caractéristiques des machines qui vont héberger une application sous Planisware 5. Pour cela il sera nécessaire de déterminer au préalable les hypothèses métier ayant un impact sur le dimensionnement global notamment :
→ le nombre d’utilisateurs concurrents
→ le type d’utilisateurs (en fonction des types de traitements qu’ils réalisent)
→ la volumétrie des données (nombre de plannings, nombre d’objets par planning, nombre de versions et de références…)
Impact du chargement des données en RAM
Afin de permettre des calculs plus rapides la totalité des données utilisées par P5 à un moment donné est chargée en mémoire. Cela permet notamment de s’affranchir des contraintes de performances liées aux bases de données, mais implique un besoin en RAM important.
Impact du fonctionnent par processus dédié
Planisware fonctionne avec différents processus. Parmi eux, ceux de type Intranet Server sont les plus dimensionnant. Chaque processus va fonctionner sur l’un des coeurs disponibles à un instant donné. Cependant, de base, un processus Planisware ne permet pas un fonctionnement « multithreadé » (ie. avec un redécoupage du processus en plusieurs threads potentiellement traitables sur ces coeurs différents).
Le cas le plus typique est le démarrage d’un Intranet Serveur en mode Master/Slave. En effet, au démarrage P5 a un besoin en puissance de calcul fort. Prenons l’exemple d’un serveur à 4 coeurs. Le processus de l’IS Master va démarrer et les calculs induits vont être traités sur un et un seul coeur (à un instant donné) même si le coeur utilisé peut changer au cours du temps. En général sur la plupart des machines le démarrage d’un IS Master induit une consommation CPU si fort que le processus va utiliser la quasi totalité de la puissance du coeur pendant la durée du chargement. On aura donc à tout instant un des coeurs du système saturé à 100%. Cependant dans le même temps les autres coeurs sont faiblement sollicités ce qui induit une charge système globale faible. Par exemple pour un serveur à 4 coeurs on aura : 1/4 = 25% (seulement 25% de charge CPU).
L’exemple suivant montre l’utilisation de chacun des coeurs sur un serveur à 4 coeurs lors du démarrage des services d’un server d’application Planisware. Les services sont lancés à t=13 min.
Utilisation des coeurs lors d’un démarrage du serveur d’application P5
On peut constater qu’au cours du démarrage de l’Intranet Server master on aura toujours un coeur qui sature mais qu’au global le serveur n’est pas saturé (il reste de la capacité CPU libre sur les autres coeurs). En effet, le processus de l’Intranet Server va consommer toute la puissance du coeur sur lequel il sera affecté par le système à un instant donné mais il ne pourra pas utiliser les autres coeurs.
Le graphe suivant montre le pourcentage d’utilisation globale du CPU du serveur :
Utilisation globale du CPU serveur
Ainsi en conclusion, les architectures modernes multi-coeurs ne sont donc pas exploitées au maximum de leurs possibilités par le progiciel Planisware 5.
Améliorations apportées par le mécanisme de « fork »
Pour améliorer la situation P5 peut être paramétré pour recourir aux mécanismes de fork lorsqu’il doit réaliser un traitement « gourmand » en ressources système. Il s’agit en fait d’un sous-processus de l’Intranet Server (IS) qui va durer le temps de réaliser le traitement gourmand puis disparaître. L’avantage étant que ce processus forké va pouvoir être dispatché par le système sur un coeur différent de celui de l’IS.
Attention cette fonctionnalité n’est disponible que sous UNIX (Linux, AIX, etc…) et pas sous Windows. C’est la raison pour laquelle ce type de plateforme est recommandé pour héberger le serveur d’application Planisware.
Améliorations attendues sous Planisware 6 (P6)
Le sujet des performances est bien souvent un sujet sensible voire critique pour beaucoup d’applications sous Planisware. Ainsi une meilleure gestion du multithreading est prévue pour Planisware 6 afin d’améliorer l’utilisation des ressources machines par le progiciel Planisware.
Sources d’améliorations non techniques
Dans cet article nous avons abordé les principaux aspects techniques du fonctionnement de Planisware 5 ayant un impact sur le sizing des serveurs hébergeant un serveur d’application Planisware. Cependant, les contraintes présentées ici impliquent de réfléchir dès la phase de conception à la manière de limiter le volume des données de l’application, par Intranet Serveur et au global. Ces aspects seront abordés dans des articles spécifiques.