BBL chez Mappy autour de Tsung

Tsung - Mappy
Rodolphe Quiédeville
Principe et généralités
27 mars 2014
Rodolphe Quiédeville (Freelance) Tsung - Mappy 27 mars 2014 1 / 54

Tsung
début développement en 2001
écrit en Erlang
publié sous GNU GPL V2
projet Idealx initialement nommé IDX-Tsunami
test de serveur XMPP
version 1.5.0 stable, 1.6.0 en route pour la release

Caractéristiques
multi protocoles
scalable (validé à 10 Millions d’utilisateurs)
pas d’interface graphique
extensible par plugins
scenarios XML avec validation XSL
sondes de monitoring
modèle Stochastic avec distribution de Poisson

Utilisateurs
Total
CMA-CGM
Ministère des ﬁnances
Dailymotion
Skyrock, Libération
LibertySurf
Grid’5000

Principe de fonctionnement
un contrôleur
0 à N injecteurs
une cible
un scenario
des logs
des rapports de résultats

Protocoles supportés en 1.5.0
HTTP/HTTPS
Websocket
Jabber/XMPP
Webdav
AMQP / MQTT / ZeroMQ (dev)
LDAP
PostgreSQL
MySQL

Installation
pre-requis : Erlang R15, erlang-crypto, ssh
package : Debian, Ubuntu, Fedora, ...
sources : Github
scripts de creation paquet .deb dans les sources
déploiement à l’identique sur le contrôleur et les injecteurs

Configuration
configuration centralisée
fichier xml par scenario
tout se fait sur le contrôlleur
modules optionnels à déployer sur les injecteurs

Fonctions avancées
variables dynamiques
gestion des cookies automatique
analyse du résulat
thinktime
données aléatoires
extension par modules erlang
boucles et tests
...

Scenario
Création du scenario
En mode proxy
$ tsung-recorder start
Starting Tsung recorder on port 8090
"Record file: /home/rodo/.tsung/tsung_recorder20131003-1633.xml"
Depuis les logs
$ log2tsung.pl

Le XML tu l’aimes ou ...

Scenario
Squelette de scenario
Example
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">
<clients />
<servers />
<options />
<load>
<arrivalphase />
</load>
<sessions>
<session>
<transaction />
<transaction />
</session>
</sessions>
</tsung>

Scenario
Tsung supporte les ENTITY
Example
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd"
[
<!ENTITY clients SYSTEM "/opt/tsung/scr/clients.xml">
<!ENTITY servers SYSTEM "/opt/tsung/scr/servers.xml">
<!ENTITY load SYSTEM "/opt/tsung/scr/load.xml">
<!ENTITY session1 SYSTEM "/opt/tsung/scr/sess1.xml">
<!ENTITY session2 SYSTEM "/opt/tsung/scr/sess2.xml">
]
>
<tsung loglevel="notice" version="1.0">
&clients;
&servers;
<options />
&load;
<sessions>
&session1;
&session2;
</sessions>
</tsung>

Scenario
La cible
Simple
<servers>
<server host="www.target.fr" port="8080" type="tcp" />
</servers>
Complexe
<servers>
<server host="192.168.0.1" port="80" weight="4" type="tcp" />
</servers>

Scenario
Les injecteurs
Simple
<clients>
<client host="foo" weight="1" />
</clients>
Complexe
<clients>
<client host="foo" weight="1" maxusers="1000" cpu="2">
<ip value="10.9.195.12"></ip>
<ip value="10.9.195.13"></ip>
</client>
<client host="bar" weight="2" maxusers="3000"/>
<client host="lorem" weight="3" maxusers="3000" cpu="4"/>
</clients>

Scenario
La charge va déﬁnir l’injection des utilisateurs
Example
<load>
<arrivalphase phase="1" duration="2" unit="minute">
<users interarrival="5" unit="second"></users>
</arrivalphase>
<users arrivalrate="1" unit="second"></users>
</arrivalphase>
<users arrivalrate="10" unit="second" maxnumber="1000"></users>
</arrivalphase>
</load>

Scenario
Les sessions, le subtile mélange des interactions
Example
<sessions>
<session name="small" probability="60" type="ts_http">
<transaction name="one">
...
</session>
<session name="extended" probability="35" type="ts_http">
<transaction name="foo">
...
</session>
<session name="rss" probability="5" type="ts_http">
<transaction name="home_ress">
....
</session>
</sessions>
Depuis la 1.5.0 on peut utiliser weight au lieu de probability

Scenario
Les transactions regroupent les requêtes en cas de besoin statistique
Example
<transaction name="home">
<request>
<http url="/" />
</request>
<request>
<http url="/img.jpg" />
</request>
</transaction>

Analyse de la réponse

dyn_variable
Les variables dynamiques sont initialisées par lecture du résultat d’une
action et peuvent être ré-utilisées dans les actions suivantes.
Example
Regexp
<request>
<dyn_variable name="nb_page" re="Page d+ on (d+)" />
<http url="/articles" method="GET" version="1.1" ></http>
</request>
<request subst="true">
<http url="/articles?page=%%_nb_page%%" method="GET" version="1.1" ></http>
</request>

dyn_variable
Utilisation du xpath ou lecture directe JSON
xpath
<request>
<dyn_variable name="field1_value" xpath="//div[2]/@value"/>
</request>
<request>
<http url="/api/object/%%_field1_value%%" method="GET" version="1.1" ></http>
</request>
JSON
<request>
<dyn_variable name="nb_page" jsonpath="field.array[3].value"/>
</request>
<http url="/articles?page=%%_nb_page%%" method="GET" version="1.1" ></http>
</request>

match
L’élément match permet de déclencher une action suivant le contenu
du résultat de la requête.
Example
<request>
<match do="loop" sleep_loop="5" max_loop="10" when="match">Retry</match>
<match do="abort" when="match">Error</match>
<http url="/index.php" method="GET">
</request>

Utilisation de variables dans
les scenarii

Appel de fonction
Appel de n’importe quelle fonction Erlang ou par evaluation de code
dans le scenario
sourcetype
<setdynvars sourcetype="erlang" callback="module_users:get_unique_id">
<var name="id1" />
</setdynvars>
eval
<setdynvars sourcetype="eval"
code="fun({Pid,DynVars})->
{ok,Val}=ts_dynvars:lookup(md5data,DynVars),
ts_digest:md5hex(Val) end.">
<var name="md5sum" />
</setdynvars>

Modules erlang
Ecriture modules métiers en ... Erlang
Example
<session name="rec20040316-08:47" probability="100" type="ts_http">
<http url="/echo?symbol=%%symbol:new%%" method="GET"></http>
</request>
</session>
symbol.erl
-module(symbol).
-export([new/1]).
new({Pid, DynData}) ->
case random:uniform(3) of
1 -> ‘‘France’’;
2 -> ‘‘Irlande’’;
3 -> ‘‘Japon’’
end.

lecture de données
Lecture d’un ﬁchier de données
Example
<setdynvars sourcetype="file" fileid="userlist.csv" delimiter=";" order="iter">
<var name="user" />
<var name="pass" />
</setdynvars>
<http url="/login.cgi" version="1.0" contents="user=%%_username%%&password=%%_pass%%&op=l
content_type="application/x-www-form-urlencoded" method="POST">
</http>
</request>

Autres sourcetype
Génération de valeurs aléatoires
random_number
<setdynvars sourcetype="random_number" start="3" end="32">
<var name="rndint" />
</setdynvars>
random_string
<setdynvars sourcetype="random_string" length="8">
<var name="passwd" />
</setdynvars>
constante
<setdynvars sourcetype="value" value="foobar">
<var name="constant" />
</setdynvars>

if, for, foreach, ...

if
Conditionnel de base
Example
<if var="tsung_userid" eq="3">
<request> <http url="/foo"/> </request>
<request> <http url="/bar"/> </request>
</if>

for et foreach
Des classiques forts utiles
for
<for var="i" from="0" to="50" incr="1">
<transaction name=""home"">
<request> <http url="/index.html"/></request>
<request> <http url="/main.js"/></request>
<request> <http url="/img.png"/></request>
</transaction>
<request subst="true"> <http url="/ping?foo=%%_i%%"/></request>
<thinktime value="40" random="true" />
</for>
foreach
<setdynvars sourcetype="erlang"callback="geomodule:get_tiles">
<var name="list_url" />
</setdynvars>
<foreach name="element" in="list_url">
<http url="%%_element%%" />
</request>
</foreach>

repeat
Sortie de boucle avec while ou until
Example
<repeat name="myloop" max_repeat="40">
...
<request>
<dyn_variable name="result" re="Result: (.*)"/>
<http url="/random" method="GET" version="1.1"></http>
</request>
...
<until var="result" eq="5"/>
</repeat>

En dev pour les devs

Le tagging de requêtes
(1.5.1 dev) Tagger des requêtes permet d’exclure celles-ci d’un run
particulier
Scenario
<request>
<http url="/" method="GET"></http>
</request>
<request tag="image">
<http url="/foo.png" method="GET"></http>
</request>
Particulièrement utile lors des phases de debugging du scénario (le
tag est loggé avec dumptrafﬁc="protocol")
Option -x
tsung -f SCENARIO.xml -x image start

Les logs

loglevel
Le niveau de log est relatif à chaque scenario
emergency
critical
error
warning
notice (default)
info
debug

ﬁchiers de log
Les logs sont tous présents sur le contrôleur mais séparé dans un
ﬁchier par injecteurs.
tsung.dump
=ERROR REPORT==== 13-Mar-2014::09:13:12 ===
** State machine <0.64.0> terminating
** Last message in was {timeout,#Ref<0.0.0.168>,end_thinktime}
** When State == think
** Data == {state_rcv,none,
{{0,0,0,0},0},
undefined,0,10000,"127.0.0.1",8080,gen_tcp,
{proto_opts,negociate,10,600000,32768,32768,undefined,
undefined},
false,1,undefined,true,undefined,
{1394,698391,114389},
4,4,false,undefined,0,[],<<>>,
{http,0,0,-1,{none,none},false,false,{false,false},[]},
0,2,524288,524288,
{dyndata,[{tsung_userid,"2"}],{http_dyndata,"tsung",[]}},
ts_http,[],undefined,full}
** Reason for termination =
** {{badmatch,false},[{erl_eval,expr,3,[]}]}

Log
Le level notice permet par exemple l’accès aux variables
scenario
<dyn_variable name="code" re="HTTP/1.1 (d+)" />
tsung0@host.log
=INFO REPORT==== 23-Nov-2013::09:17:37 ===
ts_search:(6:<0.69.0>) DynVar (RE): Match (code=<<"200">>)

dumptrafﬁc
dumptrafﬁc="protocol"
tsung.dump
#date;pid;id;http method;host;URL;HTTP status;size;match;error
1394696629.331706;<7218.63.0>;1;get;127.0.0.1;/index.html?f=0;200;1354;;
1394696629.33297;<7218.63.0>;1;get;127.0.0.1;/index.html?f=1;200;1354;;
1394696629.333824;<7218.63.0>;1;get;127.0.0.1;/index.html?f=2;200;1354;;
1394696629.334671;<7218.63.0>;1;get;127.0.0.1;/index.html?f=3;200;1354;;

dumptraffic
dumptraffic="true" permet de logger l’intégralité du traffic entre les
injecteurs et la cible
tsung.dump
NewClient:1394697656.592317:1
load:1
Send:1394697656.612861:<7218.63.0>:GET /index.html?f=undefined HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: tsung
Recv:1394697656.613965:<7218.63.0>:HTTP/1.1 200 OK
Server: Yaws 1.94
Date: Thu, 13 Mar 2014 08:00:56 GMT
Last-Modified: Tue, 26 Jun 2012 06:10:45 GMT
Etag: "3G0gq0ABxu9"
Content-Length: 1165
Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
...

Backtrace
Une erreur dans le scenario génère une trace complète sur la console
lors du lancement
Example
Starting Tsung
"Log directory is: /tmp/20140313-0911"
2542- fatal: {endtag_does_not_match,
{was,transaction,should_have_been,setdynvars}}
Config Error, aborting ! {fatal,
{{endtag_does_not_match,
{was,transaction,should_have_been,
setdynvars}},
{file,"tiny.xml"},
{line,32},
{col,9}}}

Monitoring de la cible

Erlang
Monitoring directement intégré dans Tsung
Example
<monitoring>
<monitor host="www-a" type="erlang"></monitor>
<monitor host="bigfoot-1" type="erlang"></monitor>
<monitor host="bigfoot-2" type="erlang"></monitor>
<monitor host="db" type="erlang"></monitor>
</monitoring>

SNMP
Monitoring par protocole SNMP
Example
<monitoring>
<monitor host="geronimo" type="snmp"/>
<monitor host="db" type="snmp">
<snmp version="v2" community="mycommunity" port="11161"/>
</monitor>
</monitoring>

Munin
Utilisation des sondes Munin
Example
<monitoring>
<monitor host="geronimo" type="munin"/>
</monitoring>

Action !
La commande utile :
Exécution
$ tsung -f scenario.xml -l logs/ start

Les mesures

Statistiques
request : Response time for each request.
page : Response time for each set of requests
connect : Duration of the connection establishment.
reconnect : Number of reconnection.
size_rcv : Size of responses in bytes.
size_sent : Size of requests in bytes.
session : Duration of a user’s session.
users : Number of simultaneous users (it’s session has started,
but not yet ﬁnished).
connected : number of users with an opened TCP/UDP
connection
custom transactions
HTTP status counter

tsung.log
Example
# stats: dump at 1218093520
stats: users 247 247
stats: connected 184 247
stats: users_count 184 247
stats: page 187 98.324 579.441 5465.940 2.177 9.237 595 58
stats: request 1869 0.371 0.422 5.20703125 0.115 0.431 7444062 581
stats: connect 186 0.427 0.184 4.47216796875 0.174 0.894 88665254 59
stats: tr_login 187 100.848 579.742 5470.223 2.231 56.970 91567888 58
stats: size_rcv 2715777 3568647
stats: 200 1869 2450
stats: size_sent 264167 347870
# stats: dump at 1218093530
stats: users 356 356
stats: users_count 109 356
stats: connected -32 215
stats: page 110 3.346 0.408 5465.940 2.177 77.234 724492 245
stats: request 1100 0.305 0.284 5.207 0.115 0.385 26785716 2450
stats: connect 110 0.320 0.065 4.472 0.174 0.540 39158164 245
stats: tr_login 110 3.419 0.414 5470.223 2.231 90.461 548628831 245
stats: size_rcv 1602039 5170686
stats: 200 1100 3550
stats: size_sent 150660 498530

tsung.log
Example
{
"stats": [
{"timestamp": 1317413841, "samples": []},
{"timestamp": 1317413851, "samples": [
{"name": "users", "value": 0, "max": 0},
{"name": "users_count", "value": 0, "total": 0},
{"name": "finish_users_count", "value": 0, "total": 0}]},
{"timestamp": 1317413861, "samples": [
{"name": "users", "value": 0, "max": 1},
{"name": "load", "hostname": "requiem", "value": 1, "mean":
0.0,"stddev": 0,"max": 0.0,"min": 0.0 ,"global_mean": 0
,"global_count": 0},

Les rapports

Rapports
Génération des rapports
script perl monolithique de base
scripts et templates alternatifs
Maheki

Contribuer
Docs, https://tsung.readthedocs.org/
Code, https://github.com/processone/tsung/
CI, http://jenkins.quiedeville.org/view/Tsung/
Bugtrack,
https://support.process-one.net/browse/TSUN
Irc, freenode #tsung
ML, https://lists.process-one.net/mailman/
listinfo/tsung-users

Questions ?
Rodolphe Quiédeville
rodolphe@quiedeville.org
http://blog.rodolphe.quiedeville.org/
Document publié sous Licence Creative Commons BY-SA 2.0

BBL chez Mappy autour de Tsung

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à BBL chez Mappy autour de Tsung

Similaire à BBL chez Mappy autour de Tsung (20)

Plus de Rodolphe Quiédeville

Plus de Rodolphe Quiédeville (12)

BBL chez Mappy autour de Tsung