La performance des tests fonctionnels

Vous avez un projet Java (ou avec une autre technologie Web). Si dans votre projet, vous avez des scénarios Selenium pour vous assurer que votre projet ne présente pas de régressions fonctionnelles, c'est bien, vous êtes un bon élèves. Si en plus, vos tests sont automatisés par une plate-forme d'intégration continue (du type Jenkins), alors vous méritez une mention honorable. Mais est-ce que vous avez pensé à collecter des données de performance pendant l'exécution de ces tests ?

Un outil à la rescousse

Pour nous aider dans cette tache, dynaTrace met à notre disposition un outil gratuit qui peut facilement se glisser une plate-forme existante de tests Selenium. L'outil en question se nomme "dynaTrace Ajax Edition" et vous pouvez le trouver à l'adresse suivante : http://ajax.dynatrace.com/ajax/en/

Lorsqu'on lance à la main l'outil, on alors la possibilité d'exécuter le navigateur de son choix et l'outil capturera, au cours d'une session d'analyse, toutes les requêtes qui passe par le navigateur et rendra compte du temps passé dans le réseau, celui passé dans le rendu de la page ou dans les scripts :

Chaque session est ensuite archivée. C'est donc une vision assez complète de la performance de la requête du point de vue client que nous obtenons. Si vous êtes en train de tester en lisant mes explications, vous allez surement me dire que c'est bien joli tout ça mais comment peut-on faire pour que les données soient collectées pendant l'exécution de mes tests Selenium. Rien ne l'empêche car dans les faits, dynaTrace Ajax Edition est un plugin ajouté au navigateur, il est constament présent (même lorsqu'on lance le navigateur en dehors d'une session de l'outil). Il suffit de savoir communiquer avec ce plugin ; et le langage disponible est la variable d'environnement. Pour ma part, j'en utilise 3 :

  • DT_AE_AGENTACTIVE       # active la collecte des données par dynaTrace Ajax Edition ; à noter que l'outil doit être lancé pour agréger les données capturées par le plugin
  • DT_AE_AGENTNAME    # donne un nom aux données collectées
  • DT_AE_CLEARCACHE    # nettoie le cache avant de lancer les requêtes ou non

Dans la pratique avec Selenium, vous avez surement un script de lancement votre Remote Control qui ressemblera à :

set DT_AE_AGENTACTIVE=true
set DT_AE_AGENTNAME=IDEO_SELENIUM
set DT_AE_CLEARCACHE=true
ant -Dport=5557 -Dhost=localhost -DhubURL=http://localhost:4444 -Denvironment="ie 8 windows" launch-remote-control

Dorénavant, à chaque fois que le Remote Control lancera un navigateur et que dynaTrace Ajax sera démarré, les données de performance seront archivées dans l'outil :

Les inconvénients

C'est prometteur mais ce n'est pas parfait. En tout cas, personnellement, j'y vois quelques inconvénients :

  • Tout d'abord une limitation de la version gratuite : seul les navigateurs Internet Explorer 8, 9 et 10 et Firefox 9 et 10 sont officiellement supportés. Si vous voulez supporter de plus ancienne version, il faudra soit regarder du côté de la version payante, soit rechercher d'autres outils
  • Ce n'est pas une solution centralisée : en effet, les données ne sont visibles et archivées que sur le client lourd sur le poste où le client web s'exécute. Dans le cas d'un Grid Selenium, où il y a certainement autant de machines (certainement virtuelles) que de versions de navigateur à tester, il y aura autant de client lourd dynaTrace à lancer.
  • Le suivi des performance n'est pas aisé : ce qui est principalement interressant avec ce genre de mesure, c'est d'avoir un suivi des mesures pour voir rapidement les dégradations induites par les nouveaux développements. Ici, je ne trouve pas ça évident. Tout d'abord, le nom des données archivées est celui données dans la variable d'environnement DT_AE_AGENTNAME. Il n'est donc déterminé qu'au moment de lancer le Remote Control, autant dire que toutes les archives porteront le même nom (que ce soit pour tester l'affichage d'une liste ou d'un message d'alerte). De toute façon, la comparaison n'est pas facile, il faut ouvrir les archives prendre les mesures à la main et les comparer soit même.

Un début de solution

Nous ne sommes pas pour autant totalement dépourvu si on décide de prendre le temps de développer ses propres outils. Avec l'aide de quelques paramètres, dynaTrace peut émettre une requête HTTP avec un contenu JSON synthétisant les données enregistrées pendant une session d'analyse. Avec une simple servlet et un parser du type google-gson, il est alors possible de récupérer les valeurs et de les archiver soi-même de manière centralisée.

Les paramètres sont à ajouter dans le fichier dtajax.ini dans le répertoire d'installation de dynaTrace :

-Dcom.dynatrace.diagnostics.ajax.beacon.uploadurl=http://localhost:8080/beaconstorage/endpoint
-Dcom.dynatrace.diagnostics.ajax.beacon.portalurl=http://localhost:8080/beaconstorage/endpoint
-Dcom.dynatrace.diagnostics.ajax.beacon.autoupload=true

Et la requête JSON reçu alors par votre Servlet (ou autre technologie) sera de la forme :

{
 "version":"2.0.0",
 "url": "www.mydomain.com",
 "rank":95,
 "ranks":{
 "cache": {"rank":100, "comment":"" },
 "net": {"rank":98, "comment":"" },
 "server": {"rank":94, "comment":"2 dynamic server-requests" },
 "js": {"rank":89, "comment":"4 slow JS handlers"}
 },
 "timetoimpression":1587,
 "timetoonload":1645,
 "timetofullload":2747,
 "reqnumber":9,
 "xhrnumber":0,
 "pagesize":264562,
 "cachablesize":0,
 "noncachablesize": 264562,
 "timeonnetwork": 400,
 "timeinjs": 30,
 "timeinrendering":200
}

Vous trouverez de plus ample information sur le site officiel de dynaTrace bien sûr : http://ajax.dynatrace.com/ajax/en/ mais aussi sur le blog officiel du produit : http://blog.dynatrace.com/2010/10/30/web-performance-optimization-use-cases-part-3-automation/

L’importance de bien régler ses Datasources

Je ne sais pas pour vous, mais le projet sur lequel je me trouve en ce moment (et ce n'est pas le seul) n'a pas prêté grande attention au paramétrage de ces datasources. Le projet  a pris la fâcheuse manie de positionner la capacité initiale d'un pool de connexion directement à sa valeur maximale. L'idée étant d'épargner la gestion dynamique du pool au serveur d'application (et puis surtout, il fallait positionner une valeur alors pourquoi pas celle là).

Dans cette situation, lorsqu'on regarde le comportement du pool pendant un test de charge, voici ce qui se passe :

Comportement du pool sans gestion dynamique

Comportement du pool sans gestion dynamique

Conformément à ce qu'on lui a indiqué, la capacité du pool est continuellement à 30 et le nombre de connexions actives oscille en fonction des besoins de l'application. L'application a longtemps vécu ainsi, cette configuration a gentillement été ignorée, le monde était heureux et en paix.

Mais (parce qu'à ce moment du récit, il faut un "mais"), soudain, les problèmes survinrent en production. Et ces problèmes se manifestèrent sous forme d'alertes sur la consommation mémoire au niveau de la base de données sous jacente. La solution fut rapide à trouver, elle a simplement consisté à laisser la gestion de la taille du pool directement au serveur d'application (une taille initiale à 0 et positionnement d'une fréquence de shrink) :

Comportement du pool avec gestion dynamique

Comportement du pool avec gestion dynamique

On voit bien que la capacité du pool s'adapte au besoin. Mais ce qui est étonnant, ce sont les gains obtenus. Le graphique ci-dessous montre la consommation de la PGA (une zone mémoire bien particulière) sur la base de données. Entre le 25/06 et le 28/06, nous avons effectué des tests sans gestion dynamique du pool. Du 28/06 au 30/06, nous avons effectué des tests avec la gestion dynamique du pool de connexion.

Consommation mémoire PGA

Consommation mémoire PGA

C'est donc environ 6 Go de mémoire brute que nous avons économisé et c'était bien au delà de ce nous envisagions. Ces chiffres sont à relativiser car dans notre cas de figure, nous avions 6 instances Weblogic qui utilisent chacune un pool sur cette base. Mais cela représente tout de même 1 Go par instance.

Et la surprise est venu aussi des temps de réponses utilisateurs mesurés pendant nos tests, nous avons observé des gains d'environ 10%. Ce point reste à confirmer car, d'une part,  je ne l'explique pas vraiment (peut être le temps d'attente d'une connexion est-il moindre grâce à un pool à parcourir plus petit) et, d'autre part, je ne dispose de pas beaucoup de mesures.

La morale de cette histoire est donc de ne pas négliger la configuration de vos datasources et de les dimensionner au plus juste. Cette expérience a été menée avec des serveurs Weblogic et une base de données Oracle mais je suis sûr qu'elle pourrait être réitérée avec n'importe quelle produit.