Livret blanc : Comment surveiller vos applications ?

Mesures de performance passives ou actives ?

 

Publication : mars 2010

Pour le télécharger au format

 

Résumé : il existe de nombreuses techniques de test d'applications critiques en phase de production qui poursuivent des objectifs différents. Ce livret blanc examine les deux principales techniques et démontre leur complémentarité en fonction des usages.

 

Enjeux des mesures de performance d'application

 

Le test d'applications est devenu essentiel pour s'assurer qu'elles remplissent leurs objectifs stratégiques. Cette préoccupation est naturellement intégrée durant les phases de développement des applications grâce aux tests unitaires, puis lors des phases de recette d'application grâce aux tests d'ensemble.

 

La surveillance de l'application pendant son exploitation est actuellement une préoccupation majeure des DSI pour s'assurer qu'elle reste accessible dans de bonnes conditions tout au long de son cycle de vie. Cette vision utilisateur s'accompagne de la définition de contrats de service (SLA) d'application.

 

De nombreuses méthodes existent pour orienter les DSI sur les organisations à mettre en place ou les tableaux de bord de SLA qu'il est nécessaire d'avoir en la matière. En revanche, peu de littérature est disponible sur la façon d'obtenir les informations (mesures) indispensables à la production des tableaux de bord et/ou à la correction des problèmes de performance.

 

La célèbre phrase de William Deming "On n'améliore que ce que l'on mesure" rappelle pourtant l'importance de la mesure dans la chaîne de gestion.

 

Ce livret blanc examine donc les deux principales techniques de mesure utilisées en production, leur principe de fonctionnement et leur champ d'application. Il donne également des éléments concrets sur les problématiques de mise en œuvre, incluant les éléments financiers.

 

Mesure de performance passive

Le principe : analyse des trafics d'accès à l'application à mesurer

La mesure passive de performance consiste à capturer (écouter) le trafic entre l'utilisateur et l'application pour analyser la performance des transactions (échanges). Elle suppose l'analyse des paquets échangés entre la demande utilisateur et la réponse du serveur.

Utilisation principale

Cette technique est principalement utilisée pour le diagnostic avancé et ponctuel des problèmes de performance pour des sites/utilisateurs identifiés.

Avantages principaux

La mise en œuvre est relativement facile. Elle se résume à l'installation du boîtier d'analyse des trafics. A noter toutefois, qu'il est souvent nécessaire d'identifier plus précisément un utilisateur ou un groupe d'utilisateurs pour créer des mesures associées.

Cette mesure détaillée est utile pour tester une application en phase déploiement ou investiguer un problème de performance déclaré pour un utilisateur ou un groupe d'utilisateurs.

Les inconvénients

Ces mesures sont délivrées par des boitiers spécifiques qui apportent une vision détaillée des transactions. Ils sont généralement exploités par des spécialistes.

Les mesures délivrées concernent la performance des transactions unitaires de l'application (comme le chargement d'un élément sur une page Web). Les valeurs obtenues (généralement des centaines de millisecondes) ne correspondent pas à l'unité de mesure connue de l'utilisateur (comme le temps de chargement d'une page Web complète).

Enfin, cette technique suppose qu'il existe un trafic de consultation de l'application identifiable. En effet, à supposer que la mesure soit réalisée à partir de l'analyse des trafics d'un utilisateur ou un groupe d'utilisateurs, si ces derniers n'utilisent pas l'application, il n'y aura pas de mesure. Cette irrégularité des mesures, empêche d'utiliser ce type de mesure pour des tableaux de bord de SLA (voir les irrégularités de mesure sur le graphe ci-contre).

Mesure de performance active

Principe : déroulement d'un script à intervalles réguliers sur un robot

La mesure active consiste à mettre en place sur un robot d'application, un script qui reflète à intervalles réguliers les interactions réelles d'un utilisateur sur l'application à mesurer. Il y a donc génération d'un trafic de test spécifique d'où le nom de mesure active.

Utilisation principale

Les mesures actives permettent de tester en exploitation (supervision) la performance/disponibilité d'accès aux applications. La fréquence des tests est généralement toutes les 15 minutes, 30 minutes, 45 minutes ou au maximum toutes les heures.

La technologie de mesure active est également très utilisée pour mesurer la performance/disponibilité des réseaux d'opérateurs. Dans ce domaine de mesure, le robot Cisco IP SLA est très populaire. Le graphe ci-contre illustre l'influence du délai réseau (mesuré par un robot IPSLA) sur le délai d'application (mesuré par un robot d'application).

La régularité des intervalles de test, permet de définir un ratio du bon fonctionnement des services à la base du suivi des contrats de service (SLA).

Avantages principaux

Les mesures sont faciles à lire car elles sont proches du ressenti utilisateur. Elles varient de quelques millisecondes à une ou deux secondes pour les délais réseaux et de quelques secondes à quelques dizaines de secondes pour les temps d'accès et de navigation sur une application.

Sous réserve d'un positionnement judicieux des robots, on obtient facilement une vision globale des performances d'un réseau ou d'une application pour un grand nombre de sites/utilisateurs.

La vision permanente et constante des performances du réseau ou de l'application permet de créer un référentiel de mesures à partir duquel on pourra définir des SEUILS d'alerte si le réseau ou l'application s'écarte des valeurs de consigne jugées acceptables.

Les inconvénients

Nécessité de développer un script pertinent pour tester les différents composants de l'application. Une bonne connaissance de l'application et un bon script qui sollicite les différents blocs fonctionnels de l'application permettront d'obtenir une supervision idéale de son fonctionnement.

Le déploiement et l'exploitation de nombreux robots nécessaires à une vision globale est coûteux.

Pour pallier à cet inconvénient, Alaloop dispose d'une technologie exclusive (Alaloop AppSLA) qui permet, à partir d'un robot central, de récréer les conditions de tests de robots distants.

 

 

 

 

 

 

 

Avantages comparés des 2 techniques

 

	Mesure passive	Mesure active
Principe	Capture de trafic pour analyser les temps du réseau ou d'une application	Génération de requêtes "utilisateur" à intervalles réguliers pour tester un réseau ou une application.
Utilisation principale	Troubleshooting	Supervision des réseaux & des applications Tableaux de bord de SLA
Avantage	Facilité de mise en œuvre Forage pour déterminer la cause précise du dysfonctionnement	Facilité d'exploitation des résultats de mesure Vision globale et identification rapide du domaine qui dysfonctionne (réseau, serveur, application) Constitution d'un référentiel de mesures : vision constante et régulière.
Inconvénients	Vision de détail et interprétations complexes Les délais de mesure (transactions unitaires) ne correspondent pas à une unité proche des utilisateurs Pas de vision constante : les mesures sont liées à l'existence d'un trafic de l'utilisateur	Développement d'un script.   Nécessite de déployer des robots (*)
Exemples d'outils	ART (Application Response Time) basées sur des analyses de paquets de produits commerciaux (NAM Cisco, QosMos - OEM de nombreuses solutions, Opnet) ou open source (Wireshark-Ethereal, Ettercap)	Robot infrastructure Cisco IP SLA très utilisé par les tableaux de bord des opérateurs réseaux. Robot d'application commerciaux (HP Mercury QTP, Sylktest,Wintask) ou open source (Jmeter, Selenium, SoapUI)

 

 

(*) Sauf avec la technologie Alaloop AppSLA

 

Conclusion

Les deux méthodes ont respectivement leurs avantages et inconvénients, mais elles sont avant tout complémentaires. On retiendra que les mesures actives permettent de surveiller globalement les applications et fournir des tableaux de bord de SLA, tandis que les mesures passives sont davantage adaptées à une surveillance fine des applications dès lors qu'un problème a été identifié en mesure active.