Votre site web fait-il la course en tête ?

Performance d’un service web et temps de réponse

Votre site web est-il un cheval de course ?

Le temps de réponse d’un site web est un élément essentiel de perception d’un internaute. Quelle qu’en soit la fonction, portail d’information, e-commerce, extranet, si l’affichage de la première page consultée est perçu comme long, l’internaute risque de repartir très vite vers d’autres cieux du web, au mieux, il poursuivra sa navigation avec une impression défavorable.

D’un autre côté, la tendance est à un contenu riche , illustré, voire personnalisé en fonction du profil de l’internaute, ce qui peut paraitre contradictoire avec  la recherche de rapidité.

En matière d’hébergement web, la mesure de la performance est l’indicateur ultime. Tous les indicateurs techniques de charge  des serveurs, d’utilisation de la bande passante, de taux d’I/O sur le stockage, peuvent être au vert et n’avoir aucune valeur si le temps de réponse n’est pas bon. Cet indicateur  est donc indispensable à la supervision d’un site web en plus de la disponibilité.

Et pourtant, cette mesure est rarement mise en place car elle est complexe et car souvent les donneurs d’ordre ont du mal à qualifier leurs objectifs. Nous allons donc voir comment aborder ce sujet et les solutions possibles ainsi que leur suivi dans la durée.

Le cadre méthodologique de la mesure de performance web

Avant d’aborder les solutions possibles, il est important de re-situer le cadre dans lequel cette performance se mesure.

Les différentes strates traversées par une requête web

Au moment de faire héberger et infogérer son applicatif web, il est logique que le donneur d’ordre ait des exigences en termes de performance. Inversement, l’infogéreur aura tendance à chercher à réduire sa responsabilité aux seuls composants qu’il maîtrise.

En effet, comme l’illustre le schéma ci-dessous, le circuit aller-retour d’une requête d’un internaute traverse plusieurs couches qui ne sont pas forcément du ressort de l’hébergeur:

Temps de reponse d'un site web
Circuit d’une requête sur un site web, mesure de performance et temps de réponse d’un site web

L’environnement de l’internaute

son poste de travail et l’état de son navigateur internet, le réseau local auquel il est connecté, son accès internet, le peering de son opérateur avec le reste du réseau : ces éléments sont pour la plupart hors de contrôle du client ou de l’hébergeur. Ce que l’hébergeur et le client/éditeur peuvent et doivent vérifier, c’est :

  1. la compatibilité avec les différents navigateurs et leurs versions.
  2. l’optimisation de temps de chargements des pages,

Le réseau internet entre l’internaute et l’accès internet du datacenter

le chemin suivi, la rapidité des équipements est variable, et aucune garantie de temps de transit n’est fournie sur internet.

L’infrastructure d’hébergement

A partir de l’accès internet de l’hébergeur, le flux va parcourir le réseau LAN, les load-balancers, cache et autres dispositifs, les serveurs web, les serveurs d’application, de base de données, le stockage, on peut également y rattacher les dispositif d’optimisation placés sur internet mais pilotés par l’hébergeur: un CDN, un service d’optimisation de temps de réponse,

L’applicatif web

le moteur d’application , le CMS et/ou le framework, les développements, les requêtes en bases de données, qui relèvent du client ou de son prestataire en développement. La performance d’une infrastructure peut être freinée par exemple  par des requêtes mal structurées.

Ces différents périmètres de responsabilité constituent un frein à la mise en place de mesure de temps de réponse car les acteurs ont souvent du mal à se mettre d’accord sur une méthode et l’appréciation des responsabilités. C’est une difficulté réelle, une fois ceci compris, il est toutefois tout à fait possible d’avancer.

Temps de réponse et montée en charge

Un temps de réponse ne peut être apprécié que par rapport à un niveau de charge. Un serveur de base de données qui reçoit une seule requête portant sur une volumétrie faible en environnement de développement, ne réagira pas du tout pareil qu’un serveur de production chargé d’un trafic de milliers de requêtes simultanées  et qui reçoit une demande d’indexation sur 100.000 références. Il faut donc effectuer les mesures de performance en fonction d’un niveau ou d’une montée en charge.

Les objectifs de temps de réponse

Bien qualifier les objectifs de performances d’un  site web

L’opérateur d’un site web va vouloir vérifier que:

  1. les internautes accèdent au site par les principaux fournisseurs d’accès,
  2. les temps d’accès par fournisseur d’accès sont dans une fourchette acceptable,
  3. le temps d’exécution d’une requête très représentative ne dépasse pas une durée exprimée en 0,0s,
  4. le site soit capable de respecter cette durée maximale jusqu’à un certain niveau de charge,
  5.  une dégradation de la performance en tendance puisse être observée, et identifiée avant que cela ne devienne problématique,
  6. les évolutions du site, et notamment l’enrichissement du contenu, sa personnalisation, ne dégradent pas les performances,
  7. le site soit capable d’absorber à performances constantes une augmentation du trafic,

D’autres éléments peuvent jouer: à quelle fréquence faire les mesures, à quel moment dans la journée, la semaine ?

Adapter la mesure aux enjeux et au budget

On voit que ces objectifs sont nombreux qu’ils peuvent être complexes. Ils vont impliquer des outils et une exploitation qui potentiellement couteux en mise en place, en licences, en temps d’exploitation, en maintenance et gestion des évolutions.

Par conséquent, l’une des premières questions que le client doit se poser, est quel budget, quel temps suis-je prêt à y consacrer ? Plus l’enjeu est fort, site e-commerce à fort trafic et haut niveau de transactions, plus on investira dans les mesures. Amazon ou Voyages-sncf.fr ont clairement la masse critique pour se doter les meilleurs solutions.

Inversement, un site non commerçant avec un trafic standard, ne pourra se permettre qu’un premier niveau d’analyse de performance.

Surmonter les complexités

Au vu de ces contraintes, on pourrait être tenté de renoncer,  la réponse est non bien sûr. Il est indispensable de mesurer la performance, mais il faut en accepter les limites et comprendre qu’une mesure de performances est un indicateur, qu’elle doit être interprétée et servir à faire un diagnostic.

L’hébergeur doit piloter cette mesure de performance, il doit savoir l’analyser pour réaliser un diagnostic et aider à la résolution d’un dysfonctionnement portant sur un élément de la chaîne qui n’est pas sous sa responsabilité. Il devra notamment collaborer avec le développeur du site web.

De son côté, l’opérateur du site web doit comprendre qu’il ne pourra avoir un seul responsable unique du respect du temps de réponse. Il peut responsabiliser chacun sur son domaine, mais il aura sûrement à gérer des situations où le diagnostic n’est pas simple. C’est aussi pour cela que disposer d’une mesure est importante, elle aidera  à faire le  trouble-shooting du problème.

Les différentes approches de mesures de temps de réponse

Nous allons passer en revue 3 approches et dispositifs par ordre croisasnt de complexité:

Une mesure interne et ponctuelle

Il s’agit de faire en interne sur le réseau de l’hébergeur un test de montée en charge sur une requête ou un scénario simple à la mise en production et lors de chaque changement de version. Le test est effectué à la périphérie du réseau de l’hébergeur, hors trafic sur internet. Cette mesure est effectuée à intervalle régulier et à l’occasion de chaque changement significatif.

Cette mesure offre un premier niveau de mesure satisfaisant et reste assez simple abordable.

Une mesure interne régulière sur scénario applicatif

Il s’agit de tester à intervalle très régulier un scénario applicatif automatisé et représentatif, et à en mesurer le temps d’exécution sans notion de montée en charge. Le test simule un comportement d’un internaute et mesure le temps d’exécution.

C’est la tendance  qui va être observée, l’avantage est que la mesure est régulière et permet d’anticiper ou réagir rapidement. Le coût est supérieur car le scénario doit être enregistré et mis à jour, cela implique donc une prestation récurrente d’administration.

Une mesure externe régulière sur scénario applicatif

Dans ce cas, on va placer des sondes à l’extérieur pour mesurer la performance depuis le réseau internet. 3 dispositifs sont envisageables qui sont dans un ordre croissant de coûts, richesse d’analyse, et charge de suivi:

  1. une sonde mise en place chez  l’hébergeur mais qui va interroger le site en sortant par un accès internet standard,
  2. un service de mesure de trafic, qui va collecter via un cookie, les données de  navigation de l’internaute,
  3. un service de sondes multiples externes sur différents fournisseurs d’accès et potentiellement différentes zones géographiques, c’est typiquement un service de type IP Label,

Les dispositifs 1 & 3 impliquent l’enregistrement d’un scénario applicatif et sa mise à jour. Le dispositif 2 implique une analyse des données collectées. Enfin, chacun peu impliquer des coûts de licence ou d’usage du service utilisé.

Conclusion: pragmatisme et conseils de votre hébergeur web

Même si on est très sensible à ce sujet à cause de difficultés rencontrées dans le passé, il faut l’aborder avec pragmatisme et bien qualifier ses objectifs et évaluer ces derniers en regard des enjeux réels. Ceci fait, l’hébergeur du site web doit être en mesure proposer à son client une ou deux solutions adaptées. L’éditeur qui développe la solution doit être impérativement associé à cette démarche.

Pour pouvoir mener une démarche de mesure de performance, le choix d’un hébergeur spécialisé web capable d’apporter son expérience et une vraie dimension de conseil est capital.

 

 

 

Laisser un commentaire

*

Be sure to include your first and last name.

If you don't have one, no problem! Just leave this blank.