JMeter : utiliser SQLite pour traiter les résultats d’un test de charges par palier

Dans ce billet, j’indique qu’il est possible d’utiliser SQLite pour traiter les données d’un tir de charges par palier (tutoriel ici).

Voici maintenant le mode d’emploi pour utiliser SQLite afin de traiter ses résultats de tir JMeter. Continuer la lecture de JMeter : utiliser SQLite pour traiter les résultats d’un test de charges par palier

JMeter et la création du rapport de tir de charges

Après l’exécution d’un tir de charges, il faut faire le rapport de tir avec si possible de beaux tableaux et/ou graphiques. Si vous avez déjà utilisé JMeter (ce que je présuppose) vous savez que les récepteurs de JMeter sont bien pour avoir des tableaux de résultats (en particulier celui du rapport consolidé), mais ils montrent des limites pour faire des tableaux personnalisés ou bien de beaux graphiques « parlants ».

Il se pose aussi la problématique de l’insertion des résultats affichés par les récepteurs de JMeter dans le document Word ou la présentation PowerPoint (ou OpenOffice). La capture d’écran fait un peu trop ‘bricolage’.

En général, il est préférable de récupérer les résultats au format CSV, puis de les traiter dans un tableur comme Excel ou Calc pour faire des tableaux et des graphiques (voir ce tutoriel).

Mais là aussi, on trouve des limites, notamment pour les « gros » tests de charges avec plus de 100 000 lignes de résultats. Les graphiques étant limités à 32 000 points (Excel/Calc) et les feuilles de tableur à 65 000 lignes (Calc / Excel 2000/2003) et 1 million (Excel 2007).

Une solution possible est de développer un programme « moulinette » qui va effectuer un premier traitement sur les données CSV pour réduire ou agréger les données, par exemple en calculant le temps moyen par intervalle de temps (i.e. par minute, par heure, etc.).

Une autre solution est d’utiliser un logiciel de base de données bureautiques comme Access ou Base pour gérer le grand nombre de lignes, voir cet article.

Une autre solution, que je trouve ‘sympa’, pratique et finalement assez simple pour un informaticien, c’est d’utiliser la petite base de données SQLite. Continuer la lecture de JMeter et la création du rapport de tir de charges

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

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… Continuer la lecture de Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications