Intranet ou Extranet, les webmasters font désormais face à l’obligation de maîtriser la qualité de service tout autant que la disponibilité des sites Web. Encore faut-il pouvoir évaluer l’évolution des besoins et l’aptitude des plates-formes Web à répondre correctement aux requêtes. Très rapidement, l’e-business a bénéficié de l’émergence des technologies de supervision des temps de réponse transactionnels mesurés au niveau du poste client. En effet, seule compte l’expérience utilisateur !
Traquer les temps de réponse
Être convaincu du bon niveau de disponibilité d’une base de données ou d’un middleware ne permet pas d’affirmer qu’une transaction Web a été exécutée dans des délais acceptables. L’une des façons de ” traquer ” les temps de réponse est de déployer une sonde (un agent Java, en général), au niveau des postes utilisateurs, qui va mesurer les temps d’exécution des transactions.En la matière, Candle a défriché le terrain avec sa solution CandleNet ETEWatch for Web browser. Les temps de réponse mesurés par la sonde ETEWatch sont agrégés sur le serveur ETEWatch, qui déclenchera une alerte sur une console d’administration système, en cas de dégradation des performances. Les temps de réponse sont aussi exploitables sous la forme de rapports de suivi du site.Mais la mesure des temps de réponse n’est pas le but ultime. Il faut diagnostiquer les goulets d’étranglement. Arrivé tardivement à la performance Web, BMC a pris à bras-le-corps cette problématique avec Patrol for Internet Services. Ce superviseur surveille la disponibilité et la performance de serveurs Web, l’analyse de trafic, la supervision du trafic sécurisé SSL ( Secure socket layer)…, et décompose les temps de réponse des transactions Web, pour distinguer ce qui relève de la latence serveur, des processus réseaux, des erreurs HTTP, etc. On doit aussi identifier les causes de dégradation au niveau non seulement du serveur Web mais aussi des applications en amont. C’est ce que propose Mercury Interactive avec la suite Topaz. La capture de l’expérience utilisateur (grâce à Topaz Prism) ou la simulation de ces utilisateurs (via les ActiveAgents) reste la première source d’alertes. Il reviendra toutefois à d’autres outils (tel Topaz AIM, Application Infrastructure Monitors) d’identifier l’origine du problème, en sondant les serveurs Web, ceux d’applications et de Streaming, les middlewares, etc., mais aussi en exploitant les données des consoles SNMP préexistantes.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
