| Gestion de la performance : Proactive Performance Management |  |
Performance et processus de développement 
Processus de développement
La couverture d'un risque majeur tardif nécessite la mise en place d'actions préventives en adoptant une attitude proactive permettant de couvrir le plus tôt possible les risques de performance.
Discipline Définition des exigences
La définition des exigences fixe les objectifs de performance et de charge, le dimensionnement du système et estime sa montée en charge:
- Nombre d'utilisateurs total et concurrents selon mode d'accès (LAN, Web, GPRS...) et le rôle,
- Objectifs de performance: délais moyen d'affichage d'une page, délais maximum d'affichage d'une page,
- Objectifs par Use case, ou packages de use cases:
- Description de la charge et de sa saisonnalité
- Niveau de performance attendue
- Volumétrie des données
- Estimation de la montée en charge
- Montée en charge lors de la mise en production
- Scénarios de montée en charge prévisionnelle sur 3 ans
Les exigences permettent de définir des indicateurs de charge et de performance fonctionnelle: ces indicateurs font partie du SLA (Service Level Agreement). Ces indicateurs définissent la cible du tableau de bord de performance de la Discipline Tests de performance.
Le tableau ci dessous donne un exemple de formalisation des exigences de performance, de charge et de volumétrie. L'analyse de la saisonnalité est particulièrement importante et peut dépendre:
- De l'heure dans la journée: 24/24 ou 9-18 par exemple,
- De la semaine dans le mois: édition des factures en fin de mois par exemple,
- Du mois dans l'année: 70% des prises de commande lors des fêtes de fin d'année par exemple.
Discipline Analyse, Architecture et Conception
L'architecture est l'élément clef de la performance. Les résolutions de problèmes de performance venant de l'architecture et des choix technologiques sont très intrusives et ont un coût considérable, pouvant aller jusqu'à l'abandon de projets.
La performance de l'architecture dépend principalement:
- Du dimensionnement de l'infrastructure
- Du partitionnement physique de l'application
- De l'intégration interne de l'application
- De l'intégration des systèmes externes
- De l'architecture logicielle
Dimensionnement de l'infrastructure
Le dimensionnement d'un système permet de cadrer l'infrastructure en déterminant des plages de capacités nécessaires. Par exemple "la charge du serveur Web estimé à 400 hits/secondes en crête sera absorbé par 3 ou 4 serveurs SUNFire 430 4 Gb avec deux serveur Apache multi-thread par machine."
La capacité de l'infrastructure est toujours une estimation haute et basse à partir du nombre d'utilisateur concurrent. Le mot clef est estimation. Le cadrage du dimensionnement doit être reprécisé au fur et à mesure des livraisons afin de limiter les risques liés à:
- Un sous dimensionner l'infrastructure, son extension induisant un coût non planifié,
- De sur dimensionner l'infrastructure, générant un taux d'utilisation faible des ressources.
Le dimensionnement peut être fiabilisé si des indicateurs de charge et performance sont disponibles sur une autre application techniquement similaire en production, et par des benchmarks du matériel et serveur (sans application) sur une infrastructure réseau similaire à la plate forme de production.
Dans tous les cas, la performance de l'infrastructure doit être validée par des tests et en mettant en pace l'instrumentation permettant de superviser le niveau de charge des différents éléments: réseau, routeur, Firewall, serveur...
Partitionnement
Le partitionnement d'une application en plusieurs niveaux physiques peut fortement impacter la performance globale, le passage par réseau d'un serveur à un autre créant une latence pouvant être nécessaire, mais pénalisante.
Par exemple, pour une architecture J2EE, les pages JSP doivent elles être collocalisées le code métier? Faut il utiliser des EJB Session pour séparer les deux niveaux? Faut il partitionner physiquement le système par domaines fonctionnels ? Quel est le coût du passage d'un serveur à un autre?
Le partitionnement à également un impact indirect sur les performances à cause de la gestion des transactions, le partitionnement pouvant imposer la gestion de transactions distribuées.
Intégration interne
Le partitionnement impose de mettre en place une solution d'intégration au sein de l'application (l'intégration des systèmes externes sera traitée plus loin). Le choix du middleware impacte notablement les performances, surtout à fortes charges. Les WebServices par exemple ont un impact fortement négatif sur les performances par rapport à un middleware RMI/IIOP. De plus, les WebServices consomment plus de bande passante sur le réseau.
Un autre point concerne le mode d'intégration: synchrone ou asynchrone par messagerie (JMS)
Le choix des technologies et le mode d'intégration de l'architecture impacte fortement les performances.
L'intégration de systèmes externes
La performance des systèmes externes doit être testée pour vérifier s'ils peuvent ou non supporter la charge générée par une nouvelle application, par exemple, intégration vers SAP ou un annuaire d'entreprise LDAP.
En cas d'impossibilité, deux solutions sont possibles:
- Augmenter la capacité du système externe,
- Utiliser une intégration asynchrone,
- Répliquer une partie des données (cache de données ou de requêtes).
Ces choix impactent cependant le fonctionnel, mais fonctionnel et performance ne peuvent pas être dissociés: les exigences fonctionnelles imposent des exigences de charge et de performance, mais la faisabilité / coût peut également impacter inversement le fonctionnel.
Architecture logicielle
Les principaux points de l'architecture logicielle impactant les performances sont:
- La gestion des données en mémoire en fonction de leur cycle de vie: application, session, conversation, requête.
- Le partage des ressources telles que les connexions base de données ou SAP par exemple,
- La base de données: le schéma, le mapping objet-relationnel,
- Les services techniques: transaction, sécurité, disponibilité par exemple
- La lourdeur de certains traitements consommant de nombreuses ressources CPU.
- La solution de conception qui peut plus ou moins impacter les ressources mémoire et CPU.
Tous ces points doivent être traités dans le dossier d'architecture, et les risques principaux de l'architecture doivent être décrits.
La phase d'architecture doit mettre en place un prototype ne contenant aucune fonctionnel, mais permettant de tester l'intégration technique et de faire des premiers tests de performance.
Ce prototype d'architecture est essentiel pour couvrir une partie du risque de performance.
Discipline Implémentation
L'implémentation peut impacter les performances, mais ces problèmes sont généralement plus simples à résoudre car plus localisés.
Pendant le développement, les développeurs réalisent (théoriquement) des tests unitaires pour vérifier le bon fonctionnement de leur code. Les tests unitaires doivent également porter sur la validation des performances sous la forme de tests unitaires de performance (par exemple avec JUnitPerf) exécutant des services de l'application en mesurant leur performance. Si ces performances dépassent le seuil fixé, une erreur est signalée, de même que pour un test unitaire fonctionnel.
La mise en place de ces tests impose que le code soit testable. La testabilité d'un code dépend beaucoup de sa conception. L'utilisation d'un Framewok IoC tel que Spring ou Hivemind améliorent considérablement la testabilité du code.
Ces tests permettent:
- De diagnostiquer au plus tôt des problèmes de performance,
- De faire des tests de non régression de performance.
Un risque lors du développement est de sur-optimiser le code avec une moindre lisibilité. Les équipes de développement doivent être sensibilisées aux problèmes de performance, mais en mettant des limites.
Le code de l'application doit être instrumenté pour générer des logs de performance. Ces logs peuvent être activés ou non et sont essentiels pour diagnostiquer des problèmes.
Discipline Optimisation
L'objectif de la discipline Optimisation est de résoudre les problèmes de performance pour atteindre les exigences de performances du SLA.
L'optimisation se fait en:
- Reproduisant le problème de performance à résoudre (hotspots)
- Calant des indicateurs de performance détaillés,
- Identifiant les hotspots, goulets d'étrangelement,
- Résolvant les hotspots: paramétrage, code de l'application, capacité de l'infrastructure,
- Testant l'impact sur les performances.
La démarche est itérative: la levée d'un goulet d'étranglement en fait apparaître d'autres. La démarche converge jusqu'à atteindre l'objectif de performance.
Les actions d'optimisation portent sur les différents niveaux de l'architecture: Serveurs Web, Serveurs J2EE métier, intégration, base de données. A chaque niveau, un ensemble de règles doivent être appliquées pour vérifier les
Les actions d'optimisation peuvent être plus ou moins intrusives, la démarche d'optimisation commençant par les actions les moins intrusives:
- Optimisation de l'infrastructure,
- Paramétrage des serveurs (J2EE, Web),
- Optimisation du code,
- Augmentation de la capacité de la plateforme.
L'optimisation des performances utilise des règles semblables pour les différents niveaux de l'architecture.
Par exemple, pour un Serveur Web Apache
- Le serveur soit configuré en multi-thread,
- Activer le module pthread
- Vérifier la configuration du pool de threads
- Limiter la charge du conteneur JSP
- Vérifier que les données statiques (HTML, GIF...) soient bien livrées par le serveur Apache et non pas par le conteneur de Servlet/JSP.
- Réduire le volume des données transférées
- Auditer le code HTML généré,
- Utiliser la compression HTML (gzip),
- Vérifier la compression des images, réduire le nombre de couleurs,
- Réduire le nombre de hits nécessaires pour afficher une page
- Vérifier le comportement des caches du navigateur
- Privilégier les inclusions statiques
- Réduire le nombre de sessions
- Vérifier qu'une seule session HTTP soit bien créée par session utilisateur
- Réduire le coût de l'internationalisation
- Gérer un cache de pages internationalisées
- ...
De même pour les serveurs J2EE, une base de données, une connexion Tuxedo par Jolt ou SAP par JCo.
La résolution de problèmes de performance nécessite d'utiliser des outils diagnostiques spécialisés tel que Diagnostic for J2EE de Mercury , OptimizeIt d'Inprise ou autre.
Chaque optimisation doit permettre d'enrichir les règles d'optimisation et les recommandations techniques d'architecture et de conception.
Discipline Tests
Les tests de validation de performance permettent de vérifier que les exigences de performances sont atteintes. La validation des performances inclue différents types de tests:
- Des tests de charge permettant d'évaluer des indicateurs de performance fonctionnels en exécutant des scénarios de tests utilisateurs. Les indicateurs de performance sont fonction du nombre d'utilisateurs concurrents.
- Des tests d'enrudance permettant de tester la tenue des performance et le bon fonctionnement sur une durée de test importante.
- Des tests techniques testant unitairement des fonctions du système, ces indicateurs étant exprimés en hit / secondes. Les tests techniques sont effectués avec ou sans charge simulée.
Les tests permettent de mesurer des indicateurs de performance et de charge:
- Performance de scénarios utilisateurs,
- Performances de fonctions unitaires,
- Charge de l'infrastructure (réseau, éléments de réseaux, serveurs, serveurs d'application...)
Suite à un test de performance, les indicateurs sont collectés et synthétisés dans un tableau de bord.
Le tableau de bord principal montre les indicateurs de performance utilisateurs et les compare à un autre tir ou aux objectifs de performance (SLA Service Level Agreement).
Un autre tableau de bord montre la charge généré par le tir de performance et compare les valeurs par rapport à des valeurs de seuil:
La réalisation de ces tableaux de bord peut être prise en charge par l'outil de test (LoadRunner par exemple), un outil de création de tableaux de bord, par des scripts ou manuellement. La collecte des indicateurs nécessite une plate forme de validation instrumentée et d'activer les services de mesure de performance des serveurs d'application, tel que PMI sur Websphere.
La validation des performances ne se passe que rarement sur une plate forme similaire à la plate forme de production: moins de machines, machines moins puissantes, pas d'équipements de sécurité, infrastructure réseau simplifiée.
Cette différence entre les plateformes impose d'extrapoler les résultats des tests d'une plateforme sur l'autre. Cette extrapolation induisant un risque important, la plateforme de validation doit être aussi proche que possible de la plateforme de production. Suite