Tout d’abord, j’ai eu un changement d’activité professionnelle en ce début d’année, qui m’accapare beaucoup de temps. Cela devrait se tasser et me permettre d’ajouter quelques billets sur JMeter.

Ensuite, car je travaille « in deep » dans JMeter, je suis en effet entrain d’essayer d’y ajouter un contrôleur « parallèle » pour permettre l’exécution en parallèle de requêtes HTTP pour un même utilisateur virtuel.

Ceci permettra de mieux simuler certains sites web 2.0 qui ont beaucoup de requêtes AJAX, ces dernières utilisant à bon escient les flux parallèles possibles dans un navigateur internet moderne (exemple, Firefox 3.5 c’est 6 flux parallèles). L’idée étant d’avoir un temps de réponses « écran web 2.0 » proche de celui du navigateur. En effet, aujourd’hui avec JMeter, si j’ai un écran d’un site web 2.0 ayant 10 requêtes (1 principale et 9 requêtes ‘ajax’), JMeter fera 10 requêtes en série, et donne donc un temps différent et généralement plus important que le navigateur qui lui, envoie ses 10 requêtes sur 2 à 6 flux parallèles. On peut voir ce phénomène sur Firefox avec le plugin Firebug ainsi qu’au niveau du paramètre network.http.max-persistent-connections-per-server dans Firefox > about:config.

C’est un travail difficile de développement, car la conception applicative de JMeter est « historique » (depuis 1998), et parfois empirique. La gestion des unités d’exécution s’effectuant en 1 thread = 1 VU, avec un ensemble de services disponibles par thread à un niveau élevée (très loin de la requête HTTP). Pour faire des flux parallèles, j’ai besoin de ces services à un niveau très bas (proche de la requête HTTP), et là c’est difficile.

Enfin, je pense avoir réussi à trouver une solution, j’ai maintenant un contrôleur qui sait balancer n flux parallèles, maintenant il faut faire un (gros) travail sur la préservation de l’intégrité des données partagées entre les flux parallèles…

J’espère que je vais réussir complètement à faire ceci.

Ah, j’allais oublier ! Très bonne année 2010 !

./