Problème de performance des applications web : stop aux idées reçues !

La performance d’une application web, qu’est-ce que c’est ?

Pour faire simple, c’est la vitesse d’exécution d’une page. L’enjeu actuel est de faire oublier la présence de la machine derrière l’application, et ainsi, de proposer une expérience utilisateur optimale.

On le sait maintenant depuis quelque années, une application avec des temps de réponse supérieurs à 1 à 2 secondes, c’est des ventes en moins et des utilisateurs qui se détournent de votre application / site.

Que peut-on faire pour améliorer la performance d’un site web ?

Le sujet est plus compliqué qu’il n’y parait… Souvent, les applications sont construites par assemblage de briques successives qui sont toutes inscrites dans l’histoire de l’entreprise. Le module tarifaire est une brique historique qui est toujours en AS400, le gestion des stocks est dans l’ERP, les clients sont quant à eux stockés dans le CRM… Si bien que, réaliser une commande déclenche souvent des dizaines d’appels au sein du SI et des temps de réponse variables. L’entreprise est souvent engagée dans une démarche SOA mais tout n’est pas encore parfait et c’est bien normal !

Dans ces conditions, obtenir de bonnes performances relève du parcours du combattant. Il est souvent déjà difficile de déterminer quelle est la brique limitante dans le système.

La bonne approche pour une optimisation réussie

La bonne approche consiste à réaliser un audit flash de quelques jours afin de faire l’état des lieux à l’instant T. Au delà des temps mesurés, il faut se concentrer aussi sur l’analyse théorique (très proche d’un diagramme de séquence) pour déterminer ce qu’il se passe lors d’une action sur l’application. Partant de là, on peut commencer à jouer. En utilisant l’approche « diviser pour mieux régner », on se concentre sur chacune des briques pour voir laquelle possède des temps de performance non satisfaisants. Il peut arriver qu’aucune des briques ne soit réellement en cause et dans ce cas, c’est l’architecture ou les différents appels qui sont problématiques.

Point de vigilance

Souvent, on se concentre sur une ou deux pages qui s’avère plus lentes que la moyenne… à tort ! La bonne approche consiste à mesurer les temps d’un processus entier, par exemple : la création d’un compte client associé au passage de la première commande. C’est ce temps global qu’il faut améliorer et pas seulement le temps unitaire, car un utilisateur acceptera plus facilement une page très lente parmi des pages rapides, qu’un ensemble de pages au temps de réponse moyen.

Les contres bonnes idées

Lorsque l’on a un problème de performance, on a souvent tendance à vouloir identifier rapidement le coupable ! Or, les premiers éléments auxquels on pense ne sont souvent pas la source du problème.

L’hébergement

Le premier coupable idéal qui vient en tête est souvent l’hébergement et ses performances, que l’on pense pouvoir améliorer facilement. Or, force est de constater que l’hébergement n’est que très rarement le coupable du défaut de performance. La plupart du temps, grâce au progrès des machines et des services Cloud, l’hébergement est largement assez dimensionné pour les besoins de l’application / site.

La base de données

Au même titre que l’hébergement, il est souvent facile de dire que la BDD est lente et qu’elle a des difficultés à gérer les nombreuses requêtes SQLLangage permettant de communiquer avec une base de données., ou NoSQL qui lui sont adressées. Encore une fois, on se trompe de coupable… Les BDD actuelles sont très optimisées ! Le problème vient plutôt du nombre de requêtes appelées : il est clair qu’appeler 100 requêtes pour l’affichage d’une seule page, c’est beaucoup trop !

Le super logiciel qui teste tout

Acheter un super logiciel qui teste tout… une autre illusion dont on aime se bercer ! Et l’idée est séduisante : dépenser X milliers d’euros dans un super logiciel d’analyse de performances qui va résoudre tous les problèmes. Malheureusement, on vous le déconseille car ce logiciel va simplement vous fournir des milliers de métriques que vous ne maîtriserez pas. Si le sujet des performances était aussi simple que ça, croyez-moi ça se saurait !

La vérité est que chaque application est différente par nature et donc, que seule une approche dans le détail permet d’avoir un impact significatif.

Les bonnes pistes

Les Services Web

A l’inverse, parmi les coupables souvent ignorés, on compte les nombreux appels à services web internes ou externes au SILe SI désigne le système d'informations d'une organisation.. Bien qu’individuellement ces services répondent avec des temps de réponse acceptables (de l’ordre de quelques millisecondes), c’est souvent la somme des appels qui est problématique.

L’architecture et le métier

C’est sans doute le facteur le plus dur à remettre en cause, mais c’est souvent au niveau du métier et/ou de l’architecture que réside le fond du problème.

Par exemple, prenons le cas suivant :

Un site de vente en ligne affiche la disponibilité de ses produits sur son site et ceci en temps réel. Bien que cette actualisation soit faite pour le bien du consommateur, elle a un coût substantiel sur le SI. Dès lors, il faut oser se poser la question suivante : A-t’on réellement besoin d’avoir cette information aussi à jour que ça ? Ne peut-on pas simplement partir du principe que le produit est disponible et de simplement valider à la commande que le produit est réellement disponible ? Est-ce acceptable pour le métier ? Ces questions n’ont pas de réponses évidentes mais c’est souvent au prix de cette réflexion que les vrais gains de performance sont acquis.

C’est dans la durée qu’on améliorera les choses

C’est évident mais c’est loin d’être une évidence pour tous. La performance est une démarche de tous les instants à inscrire dans l’ADN des entreprises, de la phase de la conception de l’application à la recette en incluant tous les acteurs du SI. Et pour cela, il est nécessaire de former et d’accompagner chacun pour que les performances ne soient plus un frein mais un gain.