jump to navigation

Trois points clés pour déterminer si la latence est causée par le réseau ou par les applications. 11 mars 2010

Posted by frnetworker in Diagnostic Réseau, InterMapper, OmniPeek.
Tags: , , , ,
trackback

Le réseau est le support d’un large spectre d’applications, depuis les plus simples hébergées en local comme l’email à des applications plus complexes utilisant de multiples serveurs ou encore des applications dépendantes des temps de réponses comme la VoIP. Lorsque le trafic de telles applications transite au travers de data centres, la tendance à atteindre les limites rend les latences du réseau encore plus pénalisantes. Identifier puis corriger les ralentissements devient rapidement une nécessité et peut parfois relever de l’exploit !

Mais dans ces conditions, qui est responsable de ces temps de réponses déplorables pour les utilisateurs  ? L’application elle-même ou le réseau ?

En premier lieu, nous devons définir les deux types de latence possibles réseau ou applicatif.

La latence réseau est le temps nécessaire à l’application pour envoyer une requête et à l’applicatif (sur le serveur) pour renvoyer l’accusé de réception de la requête. (Un message est renvoyé au travers TCP pour accuser la bonne réception du paquet de requête).

La latence applicative est le temps nécessaire de l’application pour traiter la requête et renvoyer les données de la réponse. C’est cette latence, mesurée par l’indice Apdex, qui permet une estimation du taux de satisfaction des utilisateurs applicatif par applicatif.

La plupart des logiciels d’analyse réseau proposent quelques outils de mesure des temps de latence mais dans la plupart du temps et à la différence d’OmniPeek, ils ne permettent pas de différencier l’origine des latences.

Voici les trois points qui vous permettront de connaitre la source de la latence : Réseau ou Applicatif et parfois même les deux à la fois.

  1. Faire la part des choses : latence réseau versus latence applicatif
    C’est bien connu, tous les problèmes des applications sont dus à des dysfonctionnements du réseau!  « Coupable tant que pas prouvé innocent ! »

    Dès lors, mesurer avec précision la latence réseau et celle des applicatifs est la preuve de la compétence et de l’impartialité des ingénieurs réseau. L’analyse des paquets est idéale pour se rendre à l’évidence. L’échange de paquets lors d’une conversation entre un poste client et une application (sur un serveur) permet de visualiser si le réseau est la source des latences constatées ou si l’application est le point de congestion. Pour cela, il suffit de comparer le temps de réponse nécessaire à l’envoi du paquet d’accusé de réception de la requête (latence réseau) et le temps de réponse nécessaire à l’envoi des informations résultant de la requête (latence applicative). Le plus souvent, l’accusé de réception est renvoyé très rapidement (quelques millisecondes) tandis que la réponse de l’application elle-même nécessite plusieurs secondes. Si c’est ce que vous constatez vous aussi, c’est que l’application  est la cause de la latence.
  2. Evaluer périodiquement les applications clés et la réactivité du réseau
    Investir dans une analyse régulière préventive des éléments clés est le meilleur outil pour détecter rapidement toute dégradation de performances. Même si cette technique ne contrôle que le temps de réponse (de latence) réseau, elle fournit des informations indispensables pour déterminer l’origine d’une dégradation des temps de réponse. Par exemple, lancer une série de Ping à intervalles réguliers à votre application de CRM peut fournir une base de mesures de référence objective des variations de performances pour les utilisateurs. (NDLR : il est évidement plus simple d’utiliser un logiciel comme InterMapper pour réaliser cet étalonnage de manière permanente et automatique). Si les valeurs commencent à augmenter, c’est que le temps de réponse du réseau est en passe de devenir problématique rapidement. Si les utilisateurs se plaignent des temps de réponse sans que votre échantillon ne montre de modification de la latence des pings, alors c’est l’applicatif lui-même (ou le serveur qui l’héberge) qui est à incriminer.
  3. Conserver des graphes de l’évolution des temps de réponse dans le temps
    Grapher le temps de réponse dans le temps, c’est disposer d’un référentiel indispensable pour détecter les variations qui nécessitent votre attention.La supervision des temps de latence vous permet de corréler  les variations avec d’autres statistiques comme par exemple la charge réseau au même moment. Ce type de monitoring (d’analyse préventive) est essentiel pour détecter au plus tôt les problèmes afin de se focaliser sur leur origine.Dans l’idéal, les temps de latence du réseau et des applications devraient être graphés en parallèle au fil du temps. La fluctuation des courbes (relative et absolue) sera toujours riche d’enseignement.Le monitoring des temps de réponse peut inclure la mise en place de seuils d’alertes automatisés. Cela permet aux ingénieurs d’intervenir sur un problème de latence réseau avant même que les performances de l’applicatif  n’en souffre, au plus grand bénéfice des utilisateurs.

Cet article est librement inspiré du blog de l’éditeur WildPackets par NetWalker

Publicités

Commentaires»

No comments yet — be the first.

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :