Performance

La recherche de performance ne doit pas être une fin en soi, elle doit correspondre à un besoin et ce besoin est fortement lié au ressenti des utilisateurs.
Le ressenti utilisateur n'est pas linéaire, un doublement du temps de réponse est ressenti par l'utilisateur comme beaucoup plus qu'un doublement.

Un temps de réponse d'une seconde n'est en général pas critique, mais deux ou trois secondes sont ressenties comme une perte de temps et sont une source d'énervement pour l'utilisateur ou le client.
Il y a par ailleurs un "palier" en dessous duquel il n'est guère, au moins économiquement, intéressant de descendre.
En effet le temps de réponse n'est vraiment senti comme gênant que lorsque l'action est terminée (la saisie ou le choix est effectué) et que l' action demandée au système dure réellement : l'utilisateur n'ayant plus rien à faire avant l'action suivante, ce temps "perdu" est très mal ressenti.
Par exemple l'attente de la réponse à une simple demande d'affichage de données est toujours très mal ressentie car l'action utilisateur est très courte, le résultat doit donc être rapide à obtenir !
Une à deux secondes constituent rarement une gêne, mais dès que l'attente dépasse trois secondes elle est fortement ressentie, plus de cinq secondes exaspèrent la plupart des utilisateurs/clients.
L'autre point à surveiller particulièrement est la régularité du temps de réponse.
Un temps de réponse qui varie de manière aléatoire entre une seconde (très bon) et 5 secondes (pas très bon) est plus mal ressenti par les utilisateurs réguliers qu'une attente constante de 3 secondes car l'utilisateur est dans l'impossibilité de prévoir la durée de l'attente et d'organiser son activité en conséquence. Au mieux ce phénomène génère une perte de temps et d'énergie, au pire il est générateur d'une sorte de "stress".
Ce type de mission peut être "léger" pour des PME / PMI dont les systèmes ne présentent en général pas la complexité des systèmes utilisés au sein des grandes entreprises et dont les problèmes sont souvent dus à une inadaptation de la base de données au logiciel et au volumes traités.

Poser le problème

Les problèmes de performance sont souvent assez délicats à résoudre car ils peuvent provenir d'une multitude de sources.
Cependant les sources les plus courantes sont :

Paramétrage inadapté
- de la base de données,
- du serveur WEB.
- d'un autre élément du système (réseau par exemple)
Saturation d'un ou plusieurs éléments liés au matériel :
- CPU serveur,
- Mémoire,
- Sous-système disque,
- Réseau,
- CPU des postes utilisateurs, en général moins important actuellement, les utilisateurs disposent en général de machines puissantes,
- ...
Programmation incorrecte.
- Ceci est particulièrement le cas pour les ordres SQL qui ne sont pas toujours optimisés et souvent pénalisés par des index inadéquats.
- Il arrive que certains éléments, par exemple la mise en historique, n'aient pas été prévus à l'origine du logiciel et que la base soit surchargée par des années de données qui devraient être archivées depuis longtemps ... car elle n'ont plus aucun intérêt pour un utilisateur "normal".
- Utilisation de la même machine pour des traitements interactifs et de traitements statistiques/commerciaux lourds qui ont tendance à donner des performances "en dent de scie".

La résolution de ce type de problème passe par :

Un audit détaillé des applications et de l'architecture matérielle et logicielle.
La définition et le choix de mesures de concert avec les utilisateurs pour permettre de définir l'état actuel des performances.
Cet état servira ensuite de point de référence pour les actions suivantes.
Il est aussi intéressant de définir la performance espérée.
La prise de ces mesures de référence « en réel », par exemple en utilisant un simulateur de charge tel que "Neoload".
Une analyse fine des mesures réalisées. Cette étape peut éventuellement « boucler » sur la définition de mesures complémentaires destinées à affiner la recherche.
Une réflexion globale définissant les stratégies possibles.
Une évaluation des gains apportés par chaque stratégie
1. Une évaluation du coût de chaque stratégie
2. Le choix des stratégies à mettre en place en fonction du rapport gain espéré / coût de mise en place.
La mise en place des stratégies choisies.
Une nouvelle prise des mesures définies précédemment afin de valider les résultats obtenus par comparaison avec la référence établie précédemment.

Audit de site web

Ce type de mission est destiné à évaluer les limites de performance d'un service Web par rapport à la charge attendue.
Les résultats permettent de dimensionner correctement le matériel et le logiciel destinés à assurer ce service ou, au moins de détecter les "goulots d'étranglement" qui limitent la charge admissible pour le temps de réponse défini avec le client.

Ce type de mission s'appuie sur des outils de simulation et de mesures permettant de suivre l'ensemble des éléments constituant le site :

Le ou les serveurs WEB
Les serveurs apportant des services
La ou les bases de données
Le ou les serveurs de base de données.
Le réseau
.....

Le logiciel utilisé apporte des résultats sous forme de tableaux et/ou de graphiques permettant de visualiser l'ensemble des mesures, l'exemple présenté a été réalisé avec l'outil "Neoload".
Il est ainsi aisé de repérer des corrélations entre la performance globale et la charge générée, la source des ralentissements en charge peut ainsi être facilement détectée et analysée.
Suite à l'analyse des actions correctives peuvent être proposées afin de corriger les défauts constatés. Après la phase de correction une deuxième passe d'analyse peut être réalisée afin de s'assurer de la compatibilité des résultats avec les besoins définis au préalable par le client.
La participation des équipes système et utilisateurs est importante dans ce type de mission.

Télécharger un exemple de rapport.