Le principal avantage de Tsung est sa capacité à générer de forts tests de charge en cluster, chaque noeud étant capable de générer une charge très importante. Il devient ainsi plus simple de mettre en place des tests de performances massifs.
Sa grande force est également son modèle de scénario et sa capacité à générer des benchmarks réalistes, sur la base d'un modèle stochastique permettant de faire varier très légèrement l'exécution des scénarii. Il s'agit de la première nouvelle version depuis le transfert du projet de la société IDEALX à la société Process-one (support commercial) et à Erlang-projects (Communauté). Le projet, anciennement baptisé Tsunami, a été renommé Tsung pour l'occasion (Pour Tsunami Next Generation).
Parmi les nouveautés, on notera que le support du protocole natif PostgreSQL a été ajouté. Il est donc maintenant possible de faire des tests sur une base de données PostgreSQL. Plusieurs améliorations sur le support de Jabber/XMPP ont également été ajoutées. De nombreux bugs ont été corrigés et le fichier de configuration XML a été revu, afin d'être plus clair.
L'outil a été utilisé dans pour tester de large cluster, simulant par exemple 25 000 utilisateurs simultanés, sur un serveur web HTTP/HTTPS, à partir de seulement 4 machines d'injection.
Pour plus d'informations, vous pouvez également consulter :
- La fiche de présentation de Tsung sur Erlang-projects
- La présentation de Tsung lors de la conférence des utilisateurs Erlang en Suède [pdf]
Aller plus loin
- Tsung (220 clics)
- Tsung - Site communautaire (80 clics)
- Process-one (43 clics)
- IDEALX (32 clics)
- Téléchargement de Tsung (67 clics)
- Liste des changements (7 clics)
# Intérêssant mais.....
Posté par duf . Évalué à 6.
Je ne connaissais pas mais étant donné que je fais des tests en charge, forcément cet outil a éveillé ma curiosité :)
Pour moi, le premier gros point fort de LoadRunner de M.I. est la GUI qui permet facilement pour la partie capture d'un scénario de modifier les différents paramètres. Je ne dis pas que la modification du fichier xml généré par Tsung soit délicate car en fait il est très lisible. Mais par exemple, lors de la validation du scénario de test, il peut être intérêssant de limiter tous les "think time" à 1s afin de ne pas mettre 5 minutes à exécuter le scénario. Hors là j'ai l'impression qu'on doit se palucher tout le fichier à la main... Bon c'est un exemple parmis d'autres, mais pouvoir jouer facilement sur ce type de paramêtre est vraiment utile lors du dev du scénario.
Bon par contre on trouve quand même les choses intérêssantes, pouvoir paramêtrer le scénario avec des variables dynamiques, utiliser un jeu de données à partir d'un fichier plat notamment pour les login/password, etc...
J'ai vu aussi qu'on pouvait checker le retour renvoyé par le serveur, normal et vital... En plus d'après ce que j'ai vu on peut checker une chaine dans la réponse du serveur ce qui est encore mieux que simplement le code retour. Car j'ai déjà vu des applis web où les mecs renvoyaient une page en code 200 avec en fait un texte d'erreur dans la page... donc si on ne peut pas positionner de vérification sur le contenu de la page, il est difficile de s'assurer de la cohérence de la page retournée.
Néanmoins en lisant la documentation, je n'ai pas trouvé comment on pouvait récupérer pour la réutiliser une valeur transmise dans la réponse du serveur ? Je m'explique, par exemple si je test une application web, avec un serveur d'application derrière le serveur de présentation HTTP, je peux avoir après une connexion, une URL qui va contenir une chaine dynamique du type JsessionID par exemple, or il faut récupérer la valeur JsessionID dans la réponse du serveur consécutive à la demande de connexion...
C'est plutot embêtant pour tester toutes les applications web, surtout qu'en fait, on a la possibilité de checker la réponse du serveur et de variabiliser facilement le scénario... Donc soit j'ai mal lu et pas trouvé, soit il manque le lien entre la réponse et la possibilité de variabiliser en fonction de la réponse.
Toujours concernant le mode HTTP, je n'ai pas trouvé si le fonctionnement de l'enregistrement du scénario pouvait se faire au choix dans un mode URL (où on enregistre chaque requête à chaque ressources de la page) ou dans un mode WEB (on enregistre seulement la requête d'accès à la page en faisant confiance aux devs pour pas faire de changement entre le début et la fin de la phase de tests).
En tout cas je trouve très encourageant ce type d'application car de mon point de vue les tests en charge deviennent de plus en plus nécessaires avant une mise en production. En même temps cela dépend aussi de l'application qui doit être mis en production :D
Sinon une petite idée, étant donné qu'on peut tester du XMPP, ne serait-il pas possible d'inclure la possibilité de faire des tests MGCP, SIP, H323... Je sais qu'il y a déjà SIPP qui existe, mais il est limité à SIP, alors qu'il pourrait être intérêssant d'avoir un outil réellement multi-protocoles. Bon certes ce type de protocole s'appréhende de manière totalement différente, c'est d'ailleurs peut être pour ça que M.I. n'a pas d'outils réellement pour ces protocoles et que le seul que je connaisse qui permettent réellement de faire des scénarios pointus ce soit dct2000 de catapult.
En tout cas félicitations pour le travail, j'ai mis Tsung dans mes bookmarks et je suis impatient de voir les prochaines versions :)
[^] # Re: Intérêssant mais.....
Posté par zarn . Évalué à 4.
<option name="thinktime" value="1" random="false" override="true"/>
2/ Pour récupérer une valeur renvoyé par le serveur et l'utiliser ensuite:
cf. section 8.6.5 de la doc (dynamic variables).
3/ Le proxy enregistreur http enregistre toutes les requêtes http faites par le navigateur; est-ce que ça répond à ta question ?
[^] # Re: Intérêssant mais.....
Posté par duf . Évalué à 3.
2/ Honte à moi, la prochaine fois j'éviterai de lire une documentation après minuit, surtout que dans mon commentaire je fais allusion à des points de la doc du chapitre 8.......
3/ OK, cela correspond au mode URL, le plus efficace. Mais est-ce qu'il y aurait un mode avec simplement les URLs d'accès au page ? En fait sous LoadRunner on peut le faire, bon ce n'est pas recommandé car il n'y a plus de requêtes unitaires pour chaque ressource de la page, mais dans certains cas ça peut être un mode de test de perf intérêssant.
Merci pour ces réponses, en tout cas cela me confirme donc qu'il n'y a pas de limites pour les tests d'applications web, c'est encore plus encourageant que ce que je pensais.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.