Jmeter pour tester la performance de JIRA

Voila un petit billet sur l'utilisation de Jmeter pour réaliser des tests de performance sur une instance JIRA. Ce n'est pas un tutoriel, juste un point de départ pour vous donner une idée des possibilités offertes par l'outil.

Jmeter est un outil qui permet facilement de tester la performance des applications WEB. Outre le fait qu'il soit gratuit, il est très complet, et permet de réaliser des tests réalistes, de tester le comportement d'une application (on peut même l'envisager pour faire des tests fonctionnels ou de non régression) et de contrôler sans beaucoup de configuration des injecteurs esclaves.

Atlassian fournit un ensemble de tests prêts à l'emploi pour valider la configuration d'une instance JIRA.

Pour tester une instance, on peut télécharger l'exécutable Jmeter ici : https://maven.atlassian.com/3rdparty/org/apache/jmeter/apache-jmeter/2.3.4-atlassian-1/apache-jmeter-2.3.4-atlassian-1.tar.gz. Les scripts à lancer sont ici : http://maven.atlassian.com/public/com/atlassian/performance/jira/performance-test/. Il faut choisir ceux qui correspondent à votre version de JIRA.

Quelques évidences : ne pas tester dans l'environnement de production!!! Les scripts créent des issues (assez faciles à retrouver il est vrai, mais quand même...). Ils modifient surtout des issues existantes (on peut faire en sorte de se prémunir de la modification des données réelles, mais c'est quand même trop risqué).

Donc, il faut absolument recréer un environnement de test, à partir de l'environnement de production (même hardware, mêmes paramètres, même base de données, ...).

Pour les impatients, on peut simplement lancer le script <jmeter location>/bin/jmeter -n -t jmeter-test-setup.jmx -Jadmin.user=<username> -Jadmin.pass=<password>, qui va créer des projets, des users, et des incidents.

Ensuite, on peut lancer Jmeter en mode GUI et ouvrir le script jmeter-test-fixedload.jmx. Il est possible de modifier les paramètres suivants pour contrôler l'exécution du script :

  • jira.host : nom du serveur JIRA
  • jira.port : port du serveur JIRA
  • jira.context : contexte de la webapp
  • admin.user : username de l'administrateur
  • admin.pass : password de l'administrateur

La liste complète des paramètres est définie ici : http://confluence.atlassian.com/display/JIRA/Performance+Testing+Scripts.

Il y a d'autres paramètres qui ne sont pas détaillés dans cette page et qui sont néanmoins importants. En voici quelques uns à titre d'exemple. Ils sont répartis un peu partout dans les paramètres de scripts, alors il faut un peu de patience et d'intuition pour les trouver :

  • scriptruntime : durée du test de charge en secondes
  • resourcedir : emplacement des fichiers de ressources
  • editIssueThreadsMax : nombre d'utilisateurs simultanés qui modifient des fiches, sur un seul injecteur (à multiplier donc par le nombre d'injecteurs en cas de test distribué)
  • addCommentPercentage : pour le script de modification de fiches, ratio d'utilisateurs qui ajoutent des commentaires.
  • Ramp Up Time : pour chaque script, durée de montée en charge, en secondes. C'est le temps que prendra le script pour passer de 0 à editIssueThreadsMax dans le cas du script de modification des issues.
  • Et plein d'autres...

On pourra aussi modifier les valeurs des timers entre chaque action, histoire d'adopter un comportement réaliste.

Les fichiers de ressources contiennent les valeurs à utiliser pour simuler la charge. Par exemple :

  • usernames.csv contient la liste des usernames à utiliser. Si on utilise des données réelles, il faut saisir des usernames existants. Dans ce cas, il est conseillé de leur donner à tous le même mot de passe, pour faciliter l'écriture des scripts de login.
  • searchterms.csv contient la liste des termes de recherche.
  • projectkeys.csv contient la liste des projets dans lesquels créer des fiches.

Si on utilise des injecteurs esclaves sur d'autres machines, il faut impérativement copier les fichiers de ressources sur tous les esclaves. Dans ce cas, le chemin d'accès au répertoire des ressources doit être complet dans les paramètres de Jmeter (en tout cas, s'il peut être relatif je n'ai pas trouvé où on devait le mettre...).

Si on veut lancer des esclaves, il faut recopier l'installation d'Apache sur chaque esclave et lancer la commande jmeter-server.[bat|sh]. Il est préférable d'utiliser des OS identiques, notamment pour que le chemin d'accès complet aux ressources soit identique sur chaque machine (on ne le fournit pas aux esclaves, c'est le contrôleur qui leur envoie).

Ensuite, dans le fichier user.properties du controleur, on fournit les adresses ou les noms des esclaves.

Lorsqu'on lance en mode controleur/esclave, on peut lancer la GUI sur le controleur. Il est également préférable de lancer l'exécution des tests sur les esclaves un par un (Run -> Nom de l'esclave) plutôt que de faire un Run All... qui souvent ne lance que le premier...

Si on ne lance pas en mode controleur/esclave, il est impératif de lancer le run en mode ligne de commande car la GUI est elle même très consommatrice en ressources. La commande pour cela est : <jmeter location>/bin/jmeter -n -t jmeter-test-fixedload.jmx.

Avant de lancer, c'est bien aussi de définir un fichier de sortie CSV, dans lequel on aura défini les informations à récupérer.

Une fois que le test de charge est lancé, on attend... (c'est la partie cool du test de charge). Et ensuite, il faut analyser les résultats. A mon avis, la première chose à regarder est le nombre d'erreurs, et leur type. En regardant en parallèle le fichier atlassian-jira.log, on pourra voir s'il y a des problèmes de dimensionnement de mémoire. Ensuite, il faut regarder les temps moyens de réponse à chaque requête. Les temps max sont intéressants, mais il ne faut pas se focaliser dessus (si une fois sur mille, un tableau de bord met 10 secondes à s'afficher, ce n'est pas la mort...). Le but du test est avant tout de vérifier que votre instance tiendra le coup. Il doit donc être réaliste. Ca ne sert pas à grand chose de simuler 5000 utilisateurs en simultané qui font tous en même temps des créations de fiches.

Voila... bons tests à tous!

bouton_atlassian_netapsys

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.