L'admin sous GNU / Linux - Blog Libre » benchmark

Réaliser des tests de performances de site web avec Tsung

Pierre-Yves Dubreucq — Thu, 16 Jun 2011 18:10:58 +0000

Comme expliqué précédemment Tsung est un outil permettant de réaliser des tests de performances multi-protocole

Je vais essayé de fournir une méthode pour installer Tsung sur une Debian (testing) plus précisemment LMDE (Linux Mint Debian) et ensuite je vais vous montrer comment réaliser des tests de performances.

Installation :

Tout d’abord, il faut installer les pré-requis :

aptitude install erlang-asn1 erlang-base erlang-corba erlang-crypto erlang-dev erlang-docbuilder erlang-edoc erlang-erl-docgen erlang-eunit erlang-ic erlang-inets erlang-inviso erlang-mnesia erlang-nox erlang-odbc erlang-os-mon erlang-parsetools erlang-percept erlang-public-key erlang-runtime-tools erlang-snmp erlang-ssh erlang-ssl erlang-syntax-tools erlang-tools erlang-webtool erlang-xmerl libsctp1 lksctp-tools

Une fois que tout est installé, il suffit de récupérer l’archive de Tsung et de la compiler.

Il existe une version paquet en .deb de Tsung pour Ubuntu mais de mon côté ça n’a pas fonctionné, la version de Erlang présent sur les dépôts différait de la version utilisée pour générer le paquet .deb

./configure
make
make install

Une fois le paquet installé, vous aurez 2 nouveaux binaires :

tsung-recorder & tsung

tsung-recorder va vous permettre de créer vos scénarios de test de performances.
tsung est l’outil qui lance le test

Comment réaliser des tests de performances :

Nous allons lancer tsung-recorder :

tsung-recorder start

Tsung-recorder va écouter sur le port 8090.

Il vous suffit ensuite de paramétrer le proxy de votre navigateur http://localhost:8090 puis de naviguer sur votre site internet.

Tsung-recorder va enregistrer toutes vos actions qui deviendront votre scénario.

Penser à lancer un stop une fois le scénario réalisé :

tsung-recorder stop

Vous retrouverez dans votre répertoire utilisateur un fichier xml qui aura un nom de ce genre :

tsung_recorder20110615-22:44.xml

Note :
Il faut penser à fermer tous les autres onglets, afin d’éviter de voir apparaître des requêtes qui seraient celle de rafraichissement automatique de page, j’ai eu le tour avec cacti par exemple.
Vous pouvez aussi désactiver les extensions générant des requêtes, j’ai pour ma part rencontré des problèmes avec l’extension LastPass

Une fois le scénario de navigation créé il faut créer le fichier de configuraiton utilisé par tsung :

Vous trouverez des exemples de fichiers de configuration dans ce dossier :

/usr/share/doc/tsung/examples/

Voici une explication basique du fichier de configuration, qui doit se trouver dans votre répertoire utilisateur, pour moi :

/root/.tsung/tsung.xml

Pour chaque phase, vous devez paramétrer l’interval entre chaque
nouvelle connection durant la phase.
Dans mon exemple, la phase dure 7 minutes, et durant ces 7 minutes
il y aura une connection toutes les 2 secondes –>

souhaite réaliser ce test.
La somme des probabilité doit toujours être de 100 –>

frequency of this type os session. The sum of all session’s
probabilities must be 100 –>

ici tsung_recorder20110615-22:44.xml –>

Une fois votre fichier paramétré, il vous suffit de lancer tsung :

pydlaptop ~ # tsung start
Starting Tsung
"Log directory is: /root/.tsung/log/20110616-12:19"

Vous avez effectué à ce moment là votre premier test de performance, reste à connaître les résultats de ce tests.

Analyser ses performances :

Suite au test de performances, il est nécessaire d’avoir une vision du résultat.

Pour cela Tsung fournit un outils qui permet de générer une page donnant accès aux données, mais fournit aussi des graphiques

Il existe l’outil tsung_stats.pl pour ça.

Tout d’abord, il faut installer les pré-requis :

aptitude install gnuplot gnuplot-nox gnuplot-x11 groff libgd2-noxpm libnetpbm10 netpbm psutils ttf-liberation libappconfig-perl libtemplate-perl

Voici comment voir les paramètres de la commande :

/usr/lib/tsung/bin/tsung_stats.pl -help

Voici la commande que j’ai lancé pour traiter les données de mon test :

pydlaptop ~ # /usr/lib/tsung/bin/tsung_stats.pl --stats .tsung/log/20110615-23\:53/tsung.log
warn, last interval (4) not equal to the first, use the first one (10)
No data for Match
No data for Event
No data for Async
No data for Errors

Vous optiendrez l’arborescence ci-dessous :

pydlaptop ~ # ls -l /home/pydubreucq/prog/tsung/.
total 808
drwxr-xr-x  2 pydubreucq pydubreucq   4096 16 juin  10:27 data
-rw-r--r--  1 pydubreucq pydubreucq   9155 16 juin  10:35 gnuplot.log
drwxr-xr-x  2 pydubreucq pydubreucq   4096 16 juin  10:27 gnuplot_scripts
-rw-r--r--  1 pydubreucq pydubreucq   5272 16 juin  10:35 graph.html
drwxr-xr-x  2 pydubreucq pydubreucq   4096 16 juin  10:32 images
-rw-r--r--  1 pydubreucq pydubreucq   6895 16 juin  10:35 report.html

Il vous suffit ensuite d’ouvrir le fichier report.html dans un navigateur pour avoir ceux-ci :

Il est également possible de réaliser des graphes comparatifs via l’outils tsplot que je ne présenterai pas ici, mais qui est très intéressant.

Pour aller encore plus loin, il est possible de générer des bases de données RRDs :

Vous pouvez générer des rrds grâce au script réalisé par Rodolphe Quiédeville

Pour cela, il faut également installer les pré-requis :

aptitude install libdbi0 librrd4 rrdtool librrds-perl

Voici le script en question :

/usr/lib/tsung/bin/tsung-rrd.pl

Dire où trouver le fichier de log de tsung dans la variable ci-dessous :

$log_file = "tsung.log";

Ou alors, vous modifiez un peu le script pour que la valeur de log_file soit un argument passé à la commande comme ci-dessous :

$log_file = "$ARGV[0]";

De ce fait pour créer les rrd il faut lancer la commande comme ci-dessous :

/usr/lib/tsung/bin/tsung-rrd.pl /root/.tsung/log/20110615-23\:53/tsung.log

Ceci génére plusieurs fichiers RRD que vous pouvez exploiter par la suite.

Libre à vous ensuite d’exploiter vos fichiers RRD ce n’est pas le but de cet article.

Liens utiles :

Site Officiel de Tsung

Documentation de Tsung

A noter que le logo utilisé pour illustrer cet article n’est pas le logo officiel, je l’avait fait il y a quelque temps et l’avait proposé à la communauté, mais ça n’avait jamais donné suite. J’en ai donc profité pour l’utilisé ici en l’agrémentant quelque peu…

Test de montée en charge (benchmark) avec des logiciels libres

Pierre-Yves Dubreucq — Thu, 18 Feb 2010 12:42:43 +0000

Cette article va vous présenter différentes solutions libres pour réaliser des tests de montée en charge, dit benchmark.

Cette idée m’est venu d’un commentaire que j’ai laissé sur le blog de Nicolargo concernant un article sur curl-loader

Mon commentaire énumérait différentes applications libres permettant de réaliser ces benchmarks et le suivi de la montée en charge.

J’ai donc décidé d’en faire un billet complet, j’avais déjà fait des billets sur Siège et Tsung

Les Applications libres de benchmarking :

Siege :

Donc pour rappel, Siege permet de faire des tests de montée en charge de vos appliactions web en simulant un grand nombre de connexions simultanées sur une ou plusieurs URLs données.
Siege rapporte le nombre totale de hits enregistrés, de bytes transférés, le temps de réponse, les accès concurrents et retourne le statut du serveur.
Siege supporte les protocoles HTTP/1.0 et 1.1, les méthodes GET & POST, les cookies, les transaction log, et l’authentification basique.

Site officiel de Siege

Tsung :

Tsung est un outils de test de performances permettant de réaliser des benchmark massif. Il est Multi-protocoles utilisant un système de plugin (HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, SSL et XMPP/Jabber)

Et chose très importante, il permet de faire des scénarios. Les scénarios permette de simuler de la montée en charge mais non sur une seul url, mais via une succession d’action, par exemple, j’arrive sur la page d’accueil, je clique sur la catégorie « Administration », je choisi l’article « Test de montée en charge avec des logiciels libres ». L’activité de l’utilisateur et le taux d’arrivée peut être aléatoire en utilisant une notion de probabilité….

Ce qui est plus proche de la vie de ton application web qu’un nombre de requêtes simultanées sur une url.

Site Officiel de Tsung

JMeter :

Jmeter permet de simuler le comportement de plusieurs utilisateurs agissant de manière simultanée initialement sur une application Web.

Il est multi-protocole et peut désormais faire ses tests sur HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, POP3(S) and IMAP(S)

JMeter permet de faire des tests de performances, de robustesse, de charge et réalise des statistiques avec graphes à l’appui.

JMeter sur Wikipedia

Très bonne ressource pour l’utilisation de JMeter

Site Officiel de JMeter

AB – Apache Benchmark :

Très simpliste, il permet de simuler x utilisateur sur une url donnée

Curl-Loader :

Permet de simuler x connections simultanées sur plusieurs urls en même temps.

Il supporte les protocole HTTP et FTP.

Curl-Loader sur Nicolargo

Site Officiel de Curl-Loader

OpenSTA :

OpenSTA permet de faire des tests de montée en charge sur les protocole HTTP et HTTPS

Il a de gros inconvénients, d’abord il n’est disponible que pour la plate-forme Windows et est vraiment difficile à prendre en main.

Site Officiel de OpenSTA

CLIF Load Injection Framework :

Clif permet de faire des tests de performances d’applications web distribuées

Plusieurs injecteurs réparties (permet de simuler d’énormes charges) vont simuler des connections simultanées en mesurant les temps de réponse, des erreurs…

Des sondes déployées sur les serveurs hébergeant les applications à tester vont mesurer l’activité RAM, CPU, Disque…

Clif gère les scénarios et fonctionne en multi-protocole (TCP, UDP, TCP, DNS, HTTP(S), JDBC, JMS, DHCP, LDAP, SIP)

Site Officiel de CLIF

Voici un schema expliquant le fonctionnement de CLIF :

Selenium :

Selenium est une suite d’outils pour tester des applications Web.

Selenium dispose d’un Add-on pour Firefox qui va vous permettre de créer vos scénarios simplement en navigant sur l’application à tester, il y a un recorder qui enregistre votre navigation et il vous suffira de la rejouer x fois pour simuler une activité utilisateur réel.

C’est assez bluffant, on peut créer ses propres scénarios très facilement sans avoir à apprendre les commandes de l’application.

Selenium peut simuler via Selenium Remote Control (RC) différents navigateurs, plateformes et même language.

Selenium Grid va permettre de mettre en place une architecture distribuées pour réaliser des tests en parallèle.

Voici un schéma expliquant son fonctionnement :

Site Officiel de Selenium

Funkload :

Funkload permet également des faire des tests de performances

Il gère également les scénarios grace à TCPWatch

Funkload génére des rapports HTML/PDF avec graphes.

Site Officiel de Funkload

TestMaker :

TestMaker offrant une version opensource et une version entreprise, il permet également de faire des tests de montée en charge.

Je le donne pour information, mais je ne détaillerais pas ici ces fonctionnalités.

Site Officiel de TestMaker

Httperf :

Httperf est également un outils pour mesurer les performances de vos applications HTTP(S)

Il peut être utilisé avec AutoBench et OpenLoad

Site officiel de httperf

Pour trouver une liste des solutions de tests opensource allez voir ce site :

OpenSource Testing Tools

La supervision de la charge des applications web :

Il est intéressant également de pouvoir jauger sur le long terme les temps de réponses de ses applications web via l’utilisation de scénarios également.

Il existe bien sur des solutions sur les solutions de supervision libres.

Cucumber-Nagios :

Cucumber-Nagios est un plugin Nagios qui permet de réaliser des scénarios de façon assez surprenant d’ailleurs.

Ceux-ci seront ensuite joués comme n’importe quel check Nagios et permettrons de suivre par exemple le temps de réponse.

Nagios-FR en parle, je vous laisse découvrir la façon de générer les scénarios avec Cucumber-Nagios

Site Officiel de Cucumber-Nagios

Zabbix :

La solution de supervision libre Zabbix comprennant gestion d’incident et de performance intégre par défaut une application permettant de réaliser des scénarios afin de tester des applications web et ainsi garder un historique des performances

Cette approche est très intéressante car combiné aux informations provenant de la supervision de base (charge CPU, RAM…) on pourra facilement identifié les sources de ralentissements.

Site Officiel de Zabbix

Et vous vous utilisez quoi pour faire vos tests de montée en charge ?

Tsung outils de benchmark multi-protocole

Pierre-Yves Dubreucq — Thu, 01 Oct 2009 07:37:35 +0000

Tsung est un outils de test de performances permettant de réaliser des benchmark massif.

Initialement créé par IDEALX sous le nom IDX-Tsunami par Nicolas Niclausse en 2000 pour stresser les serveur Jabber, ce projet à ensuite changé de nom en 2005 pour s’appeler Tsung (Pour Tsunami Next Generation).

Voici la liste de ses fonctionnalités principales :

La charge peut être distribué sur un cluster permettant à chaque noeud de générer sa propre charge
Multi-protocoles utilisant un système de plugin (HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, SSL et XMPP/Jabber)
De nombreuses adresses IP peuvent être utilisée en faisant de l’IP aliasing (eth0, eth0:1, eth0:2…)
Support du snmp pour la supervision.
Système de configuration via XML. De nombreuses sessions peuvent être utilisées pour simuler différents types d’utilisateur.
Afin de générer un trafic réaliste, l’activité de l’utilisateur et le taux d’arrivée peut être aléatoire en utilisant une notion de probabilité.
Des rapports HTML peuvent être générés en temps réel pour voir les temps de réponse, la charge CPU…

Je n’ai pas encore eu l’occasion de tester, mais ça m’a l’air assez impressionnant !!!

A noter qu’une nouvelle version vient de sortir le 28 septembre qui est la 1.3.1.

Cette version apporte le support de Pubsub (Publish-Subscribe) et MUC (Multi-User Chat) et améliore les performances (million d’utilisateurs). Ajout du support d’ajout Munin pour la supervision. Cette version apporte de nombreuses améliorations et corrections de bugs.

Pour avoir la liste complète vous pouvez consulter le changelog

J’essaieraie d’en faire un test prochainement et j’en ferait donc bien sur un retour plus complet et j’espère didactique ici

Liens utiles :

Site Officiel de Tsung

Quelques screenshots

Siege – outils de benchmark web – Nouvelle version

Pierre-Yves Dubreucq — Wed, 13 May 2009 11:03:00 +0000

Joe Dog Software vient de sortir une nouvelle version de Siege.
Pour rappel, Siege est un outil permettant de faire du benchmark de votre site web en simulant un grand nombre de connexions simultanées par exemple sur une ou plusieurs URLs données permettant ainsi de tester la montée en charge de ses applications web ou même de son serveur.
Le programme rapporte le nombre totale de hits enregistrés, de bytes transféré, le temps de réponse, les accès concurrents et retourne le statut du serveur.
Siege supporte les protocoles HTTP/1.0 et 1.1, les méthodes GET & POST, les cookies, les transaction log, et l’authentification basique. Ces fonctionnalités sont pleinement configurables par l’utilisateur.
La nouvelle version de Siege est la 2.69.
C’est nouvelle version apporte une amélioration de la gestion de la mémoire et de la notification d’erreur.
A noter que la dernière version, la 2.68, sortie le 28 Avril 2009, implémente la RFC 2617 concernant l’authentification DIGEST. Elle inclue également de nombreuses corrections de bug et de légère amélioration de fonctionnalités.

A noter que la fondation Apache propose son propre outils de Benchmark nommé ab
Il y a aussi OpenSTA, avec environnement graphique, très complet, mais ne fonctionne que sous Windows.

Liens Utiles :
Site Officiel
Changelog
Article de Tux-Planet expliquant l’installation et l’utilisation