Vue d’ensemble de la performance des applications logicielles

Dans le contexte d’une informatique virtualisée et mondialisée et d’exigences tous azimut, la performance de nos logiciels prend de plus en plus d’importance dès la phase de conception. Désormais, nous, architectes et concepteurs nous ne pouvons plus ignorer ces nouveaux besoins que sont le multiutilisateur, le multiterminal et le multiculturel.

Pour pleinement traiter la performance des logiciels nous allons discuter dans une série d’articles de plusieurs sujets importants pour chaque rôle impliqué dans le projet de réalisation. Ce premier article traite de l’organisation pour la performance et des points de passage obligatoires avant de commencer le développement du projet.

Dès le début de tout projet de conception logicielle, nous devons nous poser la question de la signification du terme « performance » pour l’équipe en charge de cette conception ? Nous avons identifié quatre problématiques recouvrant ce qui signifie précisément la performance vue par une équipe de développement logiciel : les objectifs de performance, l’architecture pour la performance, la mesure de la performance et la formation à la performance. Chaque chapitre de l’article traite l’une de ces problématiques.

Les objectifs de performance

Souvent, une exigence de performance exprimée par une maîtrise d’ouvrage se résume à « ça doit être rapide ». Cet exemple est caricatural mais il met bien en valeur le besoin d’objectivité qu’on peut attendre de ce type d’exigence quand il s’agira de vérifier que la solution logicielle y répond. Pour l’équipe de développement il va sans dire que des exigences de performance exprimée dans un style vague et subjectif ne sont d’aucune valeur.

Ce premier constat nous amène nous-mêmes à proposer et à exiger des indicateurs rigoureusement définis et mesurables. Par la suite, les objectifs de performance se devront de reposer sur ces indicateurs.

Bien entendu, ces indicateurs doivent avoir une signification pour la maîtrise d’ouvrage. Un grand classique est de définir les indicateurs qui quantifient le confort de utilisateur et l’utilisation des ressources :

• Le temps de réponse : le temps nécessaire pour réaliser une opération avec l’application. (par ex. le temps d’affichage d’une page sur un projet web). Plutôt qu’un indicateur brut, il est plus commode d’utiliser des classes de qualité: sous-optimal, optimal, sur-optimal. Pour un projet web moyen, nous pouvons dire: plus de 4 secondes c’est sous-optimal, entre 3 et 4 secondes c’est optimal, moins de 3 secondes c’est sur-optimal.
• Le débit : C’est une mesure de la charge instantanée supportée par le logiciel et son infrastructure. Pour un projet web, nous pouvons suivre le nombre de requêtes que l’application peut servir par seconde.
• L’utilisation des ressources : C’est le niveau d’utilisation des sous-systèmes du logiciel (files d’attente, base de données, caches, etc.).

Tous les objectifs définis et leur méthode de mesure sont agrégés dans un document, le plan de performance, qui est accessible et connu par toute l’équipe de conception.

Architecture

La plupart des développeurs considèrent que les optimisations en vue d’améliorer les performances sont à faire le plus tard possible. Si cette façon de faire reste applicable aux algorithmes et aux structures de données bien encapsulés dans les classes du code objet, elle est contre-productive pour ce qui concerne l’architecture du système et de ses sous-systèmes, notamment les composants de persistance et de communication.

La conception logicielle, autrement l’architecture de la solution, doit tenir compte des critères de performance. L’exemple du Notepad de Windows® illustre parfaitement ce cas. Cet éditeur de texte reste inutilisable pour des fichiers plus grands de 10 Mo. Bien qu’il s’agisse d’une limitation d’utilisation, vu de l’utilisateur, cette situation se traduit par une sous-performance. Et cette sous-performance a ses racines dans la conception de l’éditeur. D’éventuelles optimisations réalisées à la fin de l’écriture du code n’y changeront rien.

Il existe une loi empirique sur l’art des projets IT qui dit que les plus grands problèmes de performance sont introduits durant la phase initiale de conception. Nous avons identifié les raisons les plus fréquentes qui justifient cette loi :

• l’échec à corréler les objectifs (s’ils existent) avec la conception. (voir l’exemple de Windows® Notepad)
• l’utilisation dès le début des frameworks très spécifiques au lieu des abstractions standard pour l’industrie. (voir l’impact des frameworks Object Relational Mapping sur la performance des requêtes SQL)
• Les développeurs sont habitués à répondre à des problèmes plutôt que de les anticiper

Nous sommes partisans d’une approche pro-active de la recherche de performances. Cela impose de clarifier dès la phase d’architecture quels seront les points sur lesquels les efforts devront être focalisées. En d’autres termes, cela revient à anticiper les problèmes. « Faire l’autruche » n’est pas une stratégie valable en ce qui concerne la performance futur d’une solution logicielle.

Un excellent moyen d’anticiper les problèmes ou plutôt les obstacles techniques qui les engendreront est le prototypage. Il s’agit, par exemple, de mieux connaître à l’avance si un framework est adapté à nos attentes ou de faire le bon choix entre plusieurs offres logicielles pour l’implémentation d’un sous-système de persistance ou de messagerie applicative. Le prototypage va jouer un plus grand rôle dans les années à venir lorsque de plus en plus d’applications seront contraintes d’utiliser un mélange de bases de données relationnelles et NoSQL pour assurer la performance attendue.

Mesure

La liste des objectifs figurant dans le plan de performances du projet doit être souvent vérifiée par rapport à l’état courant du projet, par exemple, à chaque itération dans le cadre d’un projet Agile. Le feedback produit par ces opérations de mesure a le même impact sur la performance que celui du Sprint Burndown Chart en ce qui concerne l’itération. Si les performances effectives s’éloignent des objectifs de performance, des corrections doivent être apportées immédiatement sous peine de laisser s’installer et perdurer une situation endémique de sous-performance.

La question essentielle est d’assurer un processus de mesure équitable, un processus où chaque membre de l’équipe dispose du même point de vue sur la performance et dans lequel les données d’une itération sont comparables avec celles données issues des itérations antérieures. Pour réaliser un tel processus, nous pouvons nous focaliser sur la modélisation de la performance. Un modèle de performance formalise la corrélation des scénarios de l’application avec les objectifs du plan de performance. Il contient également les décisions de conception qui influencent la performance et leur impact sur les décisions futures.

Le modèle de performance nous permet de réaliser des tests de performance dans un cadre formalisé et répétable et donc d’obtenir un processus de mesure équitable suivant notre définition.

Les tests automatisés jouent un rôle important ici car ils offrent un feedback quotidien sur l’état du projet. Cela est particulièrement utile lorsque le projet utilise une méthode Agile comme Behavior Driven Development (BDD) pour les exigences fonctionnelles. Les spécifications narratives et évolutives de BDD (NdBdP : dans BDD les spécifications sont présentées comme des tests exécutables et pas comme des documents statiques) peuvent élever la prise de conscience sur ces aspects de la performance du projet.

Formation

L’équipe doit être préparée pour éviter de rester piégée par un état endémique de sous-performance de la solution logicielle et pour penser proactivement sur chaque tâche. Le sujet reste vaste mais en termes généraux nous suivrons le plan suivant :

Dans les prochains articles, nous traiterons en détail les concepts les plus importants décrits ci-dessus.

Cet article a été rédigé par Irinel Matei, ex expert .Net Pentalog