Surveillance du temps de réponse

, par DnC

NSS surveille le temps de réponse d’une tâche et génère des alertes.
Selon le principe de plus grande simplicité, le traitement par défaut (sans avoir à préciser de règle) est suffisant pour s’assurer du bon fonctionnement d’un site Web.

Il est cependant possible de définir de façon fine la surveillance des temps de réponse et la génération des alertes correspondantes.

Traitements par défaut

Temps de réponse anormal

Une règle implicite fait que NSS surveille en permanence le temps de réponse par rapport au temps de réponse moyen constaté pour la tâche.

Une alerte est générée avec un niveau égal à 2, ou le niveau indiqué dans la définition de la tâche, si le temps de réponse excède 4 fois le temps de réponse moyen.

Les règles TIME et MEAN décrites ci-après complètent ce test sans le modifier.

Absence de réponse ( Request Timeout )

En cas d’absence de réponse, NSS génère un code HTTP 408 ( Request Timeout ) et une erreur de niveau 6 ( Alerte ).

Règles de surveillance du temps de réponse

Le champ "Règles" de la définition de la tâche peut recevoir une ou plusieurs règles relatives au temps de réponse :

 TIME< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai inférieur à la valeur indiquée en ms.

Exemple pour une page web dont on attend une réponse généralement inférieure à 1s :
TIME>3000

La règle inverse NOT TIME peut être utile pour détecter un défaut de calcul de la page, ou une redirection sur une page de faible contenu ou toute erreur se traduisant par un temps de réponse anormalement faible. Exemple :
NOT TIME>100

 MEAN< nombre de ms : Vérifie que le serveur retourne la réponse dans un délai moyen inférieur à la valeur indiquée en ms.

NSS entretient pour chaque tâche une valeur moyenne du temps de réponse constaté sous la forme d’une moyenne mobile calculée sur les 10 dernières réponses sans autre erreur. Il s’agit du délai moyen évoqué précédemment.

Exemple pour une page web dont on attend une réponse généralement inférieure à 1s :
MEAN<1500

Cette règle est bien adaptée à la génération d’une notification à bon escient en y associant un niveau d’alerte adéquat, comme expliqué au paragraphe suivant :
MEAN<2000:5

Dans le même esprit, la règle inverse NOT MEAN peut être utile pour alerter sur une réponse anormalement et durablement brève.

Conseils pour bien configurer la surveillance du temps de réponse

Le travers des systèmes de surveillance et d’alerte consiste à trop alerter. Les temps de réponse d’une page Web dépendent de nombreux facteurs et sont très variables.

Vous voudrez être averti qu’une page web présente un temps de réponse excessif de façon durable, et non à chaque dépassement. Pour cela :

 si vous comptez sur la surveillance par défaut (vous n’avez pas fixé de règle TIME ou MEAN, ni fixé de niveau d’alerte pour la tâche, ni fixé de niveau d’alerte minimum pour l’envoi des notifications), tout va bien : vous ne serez averti qu’en cas de défaut durable.

 si vous avez fixé un niveau d’alerte pour la tâche, veillez à ce que ce niveau soit inférieur d’une unité au niveau de notification. Le mécanisme d’élévation du niveau en cas de répétition vous permettra d’être averti en cas de défaut durable.

 si vous définissez des règles TIME ou MEAN, fondez-vous plutôt sur une règle MEAN ou faites en sorte qu’une règle TIME ne provoque une notification qu’en cas de temps de réponse très élevé de façon durable.

Voici un exemple de trois règles pour une page dont on attend un temps de réponse généralement inférieur à 1s. Les commentaires supposent un niveau d’alerte de la tâche de 4 et un niveau d’alerte minimum pour l’envoi des notifications de 5 (ce sont les valeurs par défaut) :

MEAN<2000:5 Une notification sera générée si le temps de réponse moyen dépasse 2s.

TIME<10000:4 Une notification sera générée si le nombre de réponses présentant un délai supérieur à 10s est supérieur à 60 dans la même suite d’événements (élévation du niveau de 4 à 5).

TIME<1000:3 Un avertissement est inscrit dans les Alertes.

Par ailleurs, si on estime que la réponse n’a aucune raison d’être générée en moins de 30ms, on peut ajouter :
NOT MEAN>30:5

Graphe du temps de réponse

La page "Statistiques" présente un historique du temps de réponse ainsi que des statistiques :

La coloration du fond du graphique permet de repérer rapidement les alertes ( ici du jaune correspondant aux niveaux 2 et 3 ).

A propos, ce temps de réponse, c’est quoi ?

Pour comprendre ce qu’est ce temps de réponse, il faut considérer :

dans le cas d’une requête HTTP :

 qu’il ne s’agit pas du temps total de génération de la page par le navigateur (comprenant le chargement des images, du css, du code javascript et de leur interprétation), mais seulement le temps écoulé entre la demande et le chargement de la réponse. Dans le cas d’une page HTML, cela correspondrait au temps nécessaire pour le chargement du code HTML de la page, avant toute interprétation. Cela correspondrait généralement à l’instant ’start’.

 "correspondrait" car en réalité, dans le cas général, NSS ne charge qu’une partie du corps de la page. Vous pouvez connaître le nombre d’octets téléchargés en consultant le champ réponse de la table Alertes où figure par exemple : ’payload longueur = 20000’.
L’intérêt de limiter le téléchargement est de permettre de ne pas mesurer des temps dépendant du volume de la réponse.

On voit donc qu’il ne s’agit pas de la performance de la page.

dans le cas d’une requête DNS :

 qu’il s’agit de même du temps total comprenant le temps de réponse du DNS et les délais de transmission. Il ne s’agit donc pas du temps de réponse du DNS que l’on peut surveiller avec les règles QUERY TIME et MEAN QUERY TIME.

Le temps de réponse mesuré par NSS est représentatif de la charge du serveur et du réseau. Ses excès sont significatifs d’une surcharge.

N’utilisez pas un outil de mesure de la performance pour surveiller vos sites web !

De nombreux outils sont disponibles pour surveiller le temps de présentation d’une page Web, mais c’est une opération d’optimisation à effectuer en cours de développement. Après la recette de la version courante de l’application, cette performance ne dépend plus que du serveur hôte et de sa connexion au réseau. C’est à cela que s’attache NSS.

Répétons-le : utiliser un outil de suivi de la performance d’un site Web, c’est risquer de ne pas voir des quantités de défauts. Pour la plupart de ces outils en effet, une page en erreur est une page rapide !

Voyez par exemple ce que répond cet outil bien connu pour une redirection 301 erronée, débouchant sur une page vide :

Performance : 100% ; intéressant, n’est-ce pas ?