MilamberSpace - JMeter » Tests de charges

JMeter : utilisation de l’élément JDBC comme source de données pour un test de charge (partie 2)

Milamber — Sat, 13 Jun 2009 08:30:54 +0000

Nous revoilà dans la deuxième partie de ce tutoriel. Pour rappel, nous étions dans la mise en œuvre d’un test de charges, dont les données injectées proviennent directement d’une base de données et ont été récupérées par JMeter, le tout expliqué dans cette partie.

Le schéma ci-dessous montre les deux parties. Dans les lignes suivantes, on s’occupera donc de la deuxième partie.

Tout d’abord, la deuxième partie débute par un Contrôleur Simple, puis on attache directement un élément de configuration Paramètres HTTP par défaut dans lequel on configure l’adresse du serveur à tester. Pour moi, cela sera un simple serveur Tomcat avec ses applications d’exemples. Ce tutoriel détaille le scénario fonctionnel.

Ensuite vient un élément de configuration Compteur, que l’on initialise (Lancer) à 1 avec un incrément de 1. Son nom de référence sera CPT.

La requête HTTP arrive ensuite. Il y a bien entendu l’URL à appeler, mais également les paramètres à envoyer dans ce formulaire pour avoir le Prénom et Nom en résultat.

C’est ici, que nous allons utiliser les variables récupérées du billet précédent. Pour cela nous allons utiliser une fonction JMeter bien pratique puisqu’elle va évaluer une chaîne de caractères générée en tant que nom de variable. La fonction est __V() (deux soulignés et V)

Nous avons ainsi :

${__V(VAR_PRENOM_${CPT})}

qui va faire pour un CPT à 1, le nom de variable VAR_PRENOM_1 (et compris comme ${VAR_PRENOM_1})

Et comme le compteur va s’incrémenter de 1 à chaque itération, nous allons avoir ${VAR_PRENOM_1}, ${VAR_PRENOM_2}, ${VAR_PRENOM_3}, etc.

En élément fils que la requête HTTP, on peut placer de manière optionnelle, une Assertion Réponse qui vient vérifier que l’envoi du formulaire a bien fonctionné (car l’application affiche le nom et prénom qui ont été envoyés).

Il ne reste plus qu’a faire une exécution (en gardant le paramétrage en 1-1-10 du groupe d’unités)

Voici les résultats dans l’élément Arbre de résultats :

Génial, cela marche ! (vous en doutiez ? )

Ah mais que ce passe-t-il à partir de la septième itération ?

L’explication est simple, ma requête SQL ne renvoie que 6 éléments, donc JMeter ne trouvant plus d’éléments, envoi le nom de la variable… Allez, c’est facile à régler, il suffit de mettre dans le champ Maximum du Compteur CPT, la variable suivante : ${VAR_ID_#} qui, je vous le rappelle, correspond au nombre d’éléments retournés pour le champ VAR_ID. Donc ici pour nous c’est 6.

Ainsi lors de l’exécution, le compteur va re-boucler de 1 à 6 (min à max) indéfiniment.

Et voilà, vous avez donc maintenant un script JMeter qui attaque une table dans une base de données pour ensuite faire un test de charges avec ces données.

Une petite remarque pour la fin :

Si jamais vous voulez utiliser un plan de test similaire à celui du tutoriel pour un test de charge avec 1 million de lignes remontées par la requête SQL, il y a de forte chance pour qu’il y ait des problèmes de mémoire dans votre JMeter, car cela va faire 1 million de variables en mémoire (ouille!)

Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications

Milamber — Fri, 21 Dec 2007 00:27:58 +0000

Pour les « grands » tirs de charges dont l’objectif est de tester une nouvelle application J2EE (ou JEE) avant sa mise en production, et afin d’éviter les crashs le jour du lancement, on mobilise en général une équipe des différents « corps de métier » informatiques.

On aura ainsi :

les « tireurs » ceux qui vont faire le tir de charges avec un outil dédié,
les fonctionnels qui assistent les tireurs pour la scénarisation du tir,
les préparateurs de données qui sont chargés de fournir des données aux injecteurs pour le tir,
les gens du réseau pour la surveillance du trafic et de la bande passante,
les DBA pour la surveillance de l’activité de la base de données,
les superviseurs des serveurs d’applications pour monitorer l’activité de l’application,
l’équipe de développement de l’application qui croisent les doigts,
et bien sur les chefs du fonctionnel et les chefs de la technique

Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.

Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…

Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :

configuration de la taille minimum et maximum idéale pour ce type d’application
modification des paramètres de JVM pour avoir notamment un fonctionnement du Garbage Collector en (quasi) parallèle (Concurrent Mark Sweep)
réglage des unités d’exécution min et max, temps d’inactivité
réglage du pool de connexions à la base de données, avec activation du cache des requêtes SQL préparées
réglage du gestionnaire de sessions
activation du monitoring,
et d’autres petits réglages de derrière les fagots : taille des files d’attente TCP, nombre des requêtes keep-alive, etc

Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges…

Voici quelques cas, dont le problème est visible sur le serveur d’applications, mais l’origine est ailleurs :

1/ le serveur d’applications explose en OutOfMemory… C’est en général de la faute à l’application développée ou de l’utilisation du framework de persistence (genre Hibernate). Un exemple, c’est le chargement de plusieurs fois un million d’enregistrement dans la mémoire (car plusieurs centaines d’utilisateurs simulés et non plus les quelques développeurs et testeurs de la recette). On aura ainsi par exemple, 100 fois 10 Mo dans la mémoire soit au moins 1Go, donc des OutOfMemory si la taille maximum de la mémoire JVM est à 1024 Mo.

2/ le nombre maximal des unités d’exécution est atteint. C’est en général de la faute de l’application développée ou bien de la base de données. En effet si le nombre max est atteint, mais que la CPU du serveur n’est pas utilisée, on peut en déduire que les unités d’exécution sont en attente de quelque chose… Et souvent c’est de résultat de la base de données. Soit cette dernière est surchargée, soit il manque quelques index quelque part ou tout simplement il faut régénérer les statistiques de la base de données.

3/ Tout va bien sur le serveur d’application, sur la base de données, etc, mais l’application est « lente » à la réponse. Et bien là on peut se poser la question du réseau. Il convient de s’assurer que toutes les cartes réseaux soient configurées en 100 Mbits/s Full Duplex (ou en gigabit), que les switchs d’interconnexion également (port par port), et les routeurs si il y a lieu. Le mieux est de faire un test FTP (via un client classique vers le serveur, ou via JMeter). En effet, on verra que si l’une des interfaces est en 10 Mbits/s half duplex, par exemple celle du répartiteur de charges, et l’ensemble des serveurs derrière ne seront pas surchargés, mais l’application sera désespérément lente (goulot d’étranglement sur le lien réseau). (pour l’histoire, une interface réseau peut basculer en 10 Mbits/s HD tout simplement car l’auto négociation de vitesse avec le switch a échoué, et ainsi la carte prend la valeur la plus basse…

4/ Les pages de l’application affichent des erreurs 500… c’est en général un problème applicatif engendré par un problème externe. Par exemple l’atteinte du nombre maximum autorisé de fichiers ouverts pour un processus, ou bien la base de données n’accepte plus de nouvelles connexions…

Par ailleurs, on peut aussi avoir un cumul de ces problèmes, et chaque tir de charges montrent un nouveau problème…

Mais quand tout est bien réglé, c’est à dire que l’ensemble des composants de la solution est bien paramétré, avec de la logique, et bien le tir de charges se passe à merveille !

[Tutorial] JMeter : faire un tir de charges par paliers et exploiter ses résultats avec Microsoft Access

Milamber — Wed, 07 Nov 2007 00:41:18 +0000

Et voilà un nouveau tutorial sur JMeter. Il s’agit cette fois d’exécuter un tir de charges avec JMeter en utilisant des paliers de charges, c’est-à-dire que pour un même scénario, on va d’abord simuler une charge de N utilisateurs pendant une certaine période, puis après une période de montée en charges, nous simulerons N x 2 utilisateurs.

L’avantage d’un scénario par paliers est de permettre d’observer le comportement d’une application pendant une période « normale » et une période de « stress ».

Pour mieux voir son comportement, nous allons nous aider de Microsoft Access pour exploiter les temps de réponses enregistrés pendant le tir de charges, et ainsi générer rapidement un graphique. Ce dernier permettra une meilleure analyse du comportement, et sera beaucoup plus « sexy » dans un rapport de tir de charges.

Prêt à partir pour de nouvelles aventures JMeter ? Oui, alors Go sur cette page.