La page centrale de votre audit (https://www.tbs-internet.com/audit/mrtg/XXX-index.html
où XXX est le nom de votre société) vous permet de
consulter en temps réel les mesures effectuées. Cette page
se compose de 3 graphiques et d'une barre d'outils. Chaque graphique contient
le temps réel; vous pouvez cliquer dessus pour accéder à
l'historique.
Prennez en compte que l'heure affichée est l'heure GMT.
Dans un monde idéal, ce graphique ne devrait rien afficher. Le taux de perte de paquets devrait être zéro. Si des paquets sont perdus, les causes peuvent être multiples:
Note: ce graphique correspond à la colonne "Packet Loss" des statistiques serveurDEDIE.
Les temps varient en fonction de la charge des liens internet, de la charge de votre serveur et du chemin parcouru par les paquets. Si le lien est saturé ou proche de l'encombrement, les paquets passent du temps dans une file d'attente avant d'être emis. Ainsi on peut constater que les paquets iront plus vite pendant les heures creuses qu'aux heures de pointe. L'autre paramètre que rentre en jeu pour le lien est son débit: transmettre un paquet de 4600 bits sur une ligne 64 kbps prend 71.88 ms alors que sur une ligne de 1024 kbps il faut 4.49 ms. Cette question du débit de la ligne est particulièrement important pour les faibles débits (64 kbps).
Votre serveur va passer du temps à traiter ces paquets ICMP. Suivant sa charge et la qualité de sa couche TCP/IP, le paquet ICMP sera renvoyé plus ou moins vite. Enfin le chemin parcouru, c'est à dire la suite d'équipements à traverser, à l'aller comme au retour (qui bien souvent est différent), compte. Typiquement, plus la distance à parcourir est faible, plus le roundtrip devrait être court. Ainsi il est plus rapide de traverser l'atlantique via une fibre optique que par satellite. Dans une plus faible mesure, plus le nombre d'équipements à traverser est petit, plus le temps de traitement par chacun des équipements est faible.
Ce graphique vous indique donc le temps moyen et maximum d'aller et retour vers votre serveur. Vous regarderez surtout ce graphique pour déterminer si il y a des pics anormaux. La courbe verte est normalement régulière, avec une legère bosse aux heures de pointe, sans plus. La courbe bleue (les maximums) est logiquement moins régulière; néanmoins une forte irrégularité ainsi que des mesures très supérieures à la moyenne sont des signes de surcharge de la ligne et de performances aléatoires. Cela doit vous alerter.
Vous constaterez que le graphique contient une ligne pointillée rouge. Celle-ci est placée par défaut à 250 ms (mais nous pouvons vous la placer à une autre valeur). Nous considérons que depuis Washington, le temps d'aller-retour ne doit pas dépasser cette valeur. Il n'y a pas de règle en la matière, mais ce chiffre nous semble à ne pas dépasser. Cette ligne doit vous aider à voir rapidement si vos résultats correspondent à vos objectifs.
Note: ce graphique correspond à la colonne "avg/max" des statistiques
serveurDEDIE.
Ce graphique permet de voir comment se comporte la consultation web au cours du temps, et en particulier pendant les phases de charge, heures pleines, et de perte de paquets. Vous remarquerez des pics sur ce graphique lorsqu'il y a des pertes de paquets, vous y verrez des bosses si votre serveur a des périodes de charge, etc. C'est un indicateur de bonne santé, sans être aussi précis que les deux autres graphiques.
Nous utilisons également une ligne pointillée rouge qui par défaut se trouve à 500 ms. Nous avons choisi ce temps arbitrairement mais nous le changeront pour vous sur demande. Cette demi seconde, c'est pour nous un objectif de vitesse de chargement de la première page d'un web (sans images). Un réponse dans ce délai permet à l'utilisateur de savoir rapidement qu'il y a quelque chose derrière, et l'aide à prendre patience. Plus le temps d'attente entre la saisie de l'URL est la modification de la fenêtre est grande, plus l'utilisateur sera tenté de zapper.
Notez que sur ce graphique on retrouve le résultat des deux graphiques
précédents. On constate également le handicap des
sites à faible débit (64 kbps) sur ce type de test.
Notre message d'alerte est envoyé au responsable que vous avez désigné. Ce message contient la cause de l'alerte, la trace PING ainsi que le timestamp du début du PING, une trace MTR et le timestamp du début de MTR. Notez qu'il est normal que MTR donne des valeurs de rountrip différentes de celles du PING car MTR utilise des petits paquets ICMP alors que notre PING utilise des paquets de taille moyenne. Un message de fin d'alerte est envoyé quand la situation redevient normale.