Le taux de surcharge des APM (Applications Performance Management)

Les APM (Applications Performance Management) sont des solutions de supervision des applications dont la valeur ajoutée consiste à apporter des informations pertinentes pour le diagnostic des dysfonctionnements applicatifs.

L’un des critères discriminants dans le choix d’un APM est son taux de surcharge ou d’overhead. Ce taux doit être rapporté au temps d’exécution d’une transaction utilisateur. Il s’agit d’un élément marketing très important car ces solutions sont essentiellement destinées à être utilisées dans des environnements de production. Les éditeurs positionnent leur produit plus largement ce qui constitue une source de revenu supplémentaire mais la finalité reste un déploiement en production. Dans ce contexte il n’est pas concevable de dégrader trop significativement le temps d’exécution des applications.

La plupart des éditeurs annoncent un taux de surcharge de l’ordre de 1 à 2% du temps global d’exécution. Cela veut dire qu’avec un taux d’overhead de 2%, le temps d’exécution d’une opération qui s’exécute en 5 secondes avant l’installation de l’agent de supervision, augmentera de 100 ms après installation du même agent. Pour la majorité des applications de gestion cette dégradation du temps d’exécution est imperceptible et tolérable, bien qu’elle puisse devenir une réelle contrainte pour des applications plus critiques (par exemple le passage des ordres de bourse).

Que dire du modèle économique d’une solution qui se positionnerait sur le marché avec un taux d’overhead de l’ordre de 10%? Je vous rassure aucun éditeur ne s’aventure sur cette voie.

Il n’est pas question dans cet article de remettre en question la valeur ajoutée des APM qui deviennent incontournables pour diagnostiquer des dysfonctionnements applicatifs mais simplement d’apporter un éclairage sur la taux de surcharge de ces solutions. Notons que ces produits différent des « profiler » qui ne peuvent être utilisés efficacement que sur des environnements de développement ou l’on a peu de concurrence d’accès.

Comment sont définis ces taux d’overhead? Quelle stratégie est utilisée pour superviser le code applicatif? Quelles sont les conséquences des différentes stratégies mises en place sur le taux d’overhead? Ce sont quelques questions auxquelles, nous allons essayé de répondre dans cet article pour vous permettre de qualifier cette information.

Vous l’aurez compris le taux d’overhead n’est qu’un indicateur marketing qui permet de rassurer les éventuels clients et éventuellement de se distinguer par rapport à une solution concurrente. Etant donné que tous les éditeurs annoncent des taux de surcharge très faibles et voire identiques, cet indicateur n’est plus réellement pertinent.

Comment fonctionnent ces solutions et pourquoi y a t-il un overhead?

La supervision du code applicatif repose essentiellement sur deux stratégies d’implémentation qui ne sont d’ailleurs pas exclusives l’une de l’autre. La première stratégie consiste à instrumenter le code à la volée lors du chargement d’une classe par la machine virtuelle, l’autre stratégie repose sur l’analyse statistique de échantillonnage des piles de thread de l’application.

Dans le cas de l’instrumentation du code, pour capturer les événements se produisant pendant l’exécution des applications, les solutions doivent ajouter du code à l’intérieur des applications. Cette injection de code est réaliser généralement au moment du chargement d’une classe par l’intermédiaire d’un agent logiciel. L’agent permet de mesurer, collecter, consolider, transmettre des informations élémentaires sur le fonctionnement de l’application à une autre partie de la solution APM. Selon les produits, la solution peut également être accompagnée d’un agent dit « système » qui collecte des informations sur le fonctionnement de l’infrastructure de déploiement (un serveur). Dans le cas de l’échantillonnage, les traitements applicatifs sont stoppés plusieurs dizaines de fois par seconde pour collecter et analyser les traces de l’exécution de l’application.

Quelle que soit la stratégie mise en place, le déploiement de ces solutions génère une surcharge sur le fonctionnement de l’application. Pour éviter que le paramétrage des agents ne perturbent trop le fonctionnement des applications, les éditeurs livrent leurs solutions avec un paramétrage par défaut qui simplifie l’installation et la configuration des produits.

Par défaut, l’instrumentation du code est réalisée sur les APIs standardisées. En JEE, les APIs d’accès aux données (JDBC), de gestion des transactions (JTA), de gestion des protocoles de communication (HTTP, RMI, …), etc, sont pré configurés directement dans la solution. Cette instrumentation permet d’obtenir, par exemple, un découpage macroscopique du temps d’exécution d’une transaction métier selon les couches de l’application qui sont traversées. C’est bien évidemment sur cette base que les taux d’overhead sont évalués.

Comment les éditeurs évaluent ils le taux de surcharge? Il n’y a pas de calcul qui permet d’établir le taux de surcharge. Les éditeurs évaluent un impact mineur si on limite le périmètre d’instrumentation aux APIs standards ou si la fréquence d’échantillonnage est diminuée. Globalement 1, 2 ou 5%, c’est une information marketing uniquement, qui ne repose sur aucun calcul scientifique (tout au plus quelques tests sur une application de référence). Mais ce paramétrage peut s’avérer insuffisant, car il ne prend pas en compte les spécificités de l’architecture de l’application.

Pour illustrer ces propos, imaginons une application de type web de gestion d’un parc de résidences hôtelières qui implémente la complexité des règles de réservation au travers de l’utilisation d’un moteur de règles. Supposons que l’acte de réservation présente un temps d’exécution nominal de 10s se répartissant de la façon suivante : 2s pour l’accès aux données, 6s pour l’exécution des règles de réservation, et 2s pour les interactions diverses dans l’application. Dans ce cas, l’instrumentation par défaut vous présentera une répartition du temps de traitement comme suit : 2s pour l’accès aux données, 8s dans la couche Http.
Vous conviendrez donc que ce paramétrage par défaut n’est pas adapté au diagnostic des dysfonctionnements, surtout ci ces derniers proviennent d’une utilisation approximative du moteur de règles. Dans notre cas, vous n’aurez aucun moyen d’établir un diagnostic précis qui permette d’optimiser le fonctionnement de l’application.
Il en est de même pour les solutions qui utilisent la stratégie de sondage qui ne révélera pas certains types de dysfonctionnement notamment ceux pour lesquels le temps de traitement est réparti sur une multitude d’appel de méthode.

Pour répondre à ces limitations, les éditeurs permettent aux utilisateurs des solutions de définir des règles d’instrumentation plus spécifiques à l’application supervisée. Cela correspondrait dans notre exemple, à permettre d’instrumenter certaines APIs du moteur de règles pour obtenir une vision plus précise du fonctionnement de notre application.

A partir de ce moment là, nous rentrons dans une phase d’expérimentation qui peut conduire à dégrader significativement les temps d’exécution des transactions de l’application. On peut ainsi s’éloigner singulièrement du taux de surcharge de 1 à 2% présenté initialement par l’éditeur.

Pour limiter cet impact et assurer un niveau de supervision qui convienne, il faudra donc rechercher un compromis entre la justesse de la supervision et la surcharge de l’APM sur le fonctionnement de l’application.

Publicités

A propos jlerbsc

founder of JavaPerf Consulting Http://www.jperf.com
Cet article a été publié dans performance. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

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