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 quelques 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.
Le sujet est plus compliqué qu’il n’y paraît… 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, la 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 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.
Souvent, on se concentre sur une ou deux pages qui s’avèrent 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.
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.
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.
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 !
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.
À 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.
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 é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.
Quelles sont les avantages en termes de performance et de disponibilité offerts par les systèmes distribués ? Exemples de solutions et difficultés de mise en œuvre.
Réaliser des tests de performances sur une application n’est jamais simple. Il est en effet assez complexe de simuler une montée en charge réaliste, ainsi qu’une activité utilisateur cohérente. Nous allons explorer quelques pistes pour y parvenir
Vous vous demandez si toutes vos images doivent obligatoirement être au format 3840 x 2160 ? Est-il nécessaire de charger celles qui ne sont pas visibles à l'écran ? Dans cet article, nous aborderons ces questions et explorerons des solutions d'optimisation, notamment grâce à la technique du lazy loading.