It’s the same approach as HTTP: first you start to record one or more sessions with the recorder: tsung-recorder -p webdav start.
By default, the HTTP plugin is used to benchmark HTTP servers. But you can also benchmark HTTP Proxy servers. To do that, you must add in the options section:
<option type="ts_http" name="http_use_server_as_proxy" value="true"></option>
An LDAP plugin for the recorder is not yet implemented, so you have to write the session by yourself; see section Authentication for more information.
It’s the same approach as HTTP: first you start to record one or more sessions with the recorder: tsung-recorder -p pgsql start.
This will start a proxy listening to port 8090 and will proxy requests to 127.0.0.0:5432.
To choose another port and/or address: tsung-recorder -L 5432 -I 10.6.1.1 -P 5433 -p pgsql start.
This will start a proxy listening to port 5432 and will proxy requests to 10.6.1.1:5433.
A MySQL plugin for the recorder is not yet implemented, so you have to write the session by yourself; see section MySQL for more information.
This paragraph explains how to write a session for Jabber/XMPP.
There are two differences between HTTP and Jabber testing:
Since the Jabber plugin does not parse XML (historically, it was for performance reasons), you must have a way to tell when a request is finished. There are 3 possibilities using the ack attribute:
ack="local" as soon as a packet is received from the server, the request is considered as completed. Hence if you use a local ack with a request that do not require a response from the server (presence for ex.), it will wait forever (or until a timeout is reached).
ack="no_ack" as soon as the request is send, it is considered as completed (do not wait for incoming data).
ack="global" synchronized users. its main use is for waiting for all users to connect before sending messages. To do that, set a request with global ack (it can be the first presence msg:
<request> <jabber type="presence" ack="global"/> </request>
You also have to specify the number of users to be connected:
<option type="ts_jabber" name="global_number" value="100"></option>
To be sure that exactly global_number users are started, add the maxnumber attribute to users:
<users maxnumber="100" interarrival="1.0" unit="second"></users>
If you do not specify maxnumber, the global ack will be reset every global_number users.
New in 1.2.2: This version adds an new option for a session. if you set the attribute bidi (for bidirectional) in the <session> tag: <session ... bidi="true">, then incoming messages from the server will be analyzed. Currently, only roster subscription requests are handled: if a user received a subscription request (<presence ... type="subscribe">), it will respond with a <presence ... type="subscribed"> message.
You can send messages to offline or online users. A user is considered online when he has send a presence:initial message (before this message , the state of the user is connected).
If you want to switch back to connected before going offline, you can use a presence:final message:
presence:final does two things:
presence:final is optional.
Warning: this is new in 1.2.0, in earlier version, only 2 status were available: online and offline; a user was considered online as soon as it was connected.
Below are configuration examples for the possible authentication methods. Note: the regular expressions used here are only examples - they may need to be altered depending on how a particular server implementation composes messages (see also Websocket options for password settings).
plain authentication - sends clear-text passwords:
<session probability="100" name="jabber-plain" type="ts_jabber">
<request> <jabber type="connect" ack="local"></jabber> </request>
<thinktime value="2"></thinktime>
<transaction name="auth_plain">
<request> <jabber type="auth_get" ack="local"></jabber> </request>
<request> <jabber type="auth_set_plain" ack="local"></jabber> </request>
</transaction>
...
</session>
digest authentication as described in XMPP JEP-0078: Non-SASL Authentication http://www.jabber.org/jeps/jep-0078.html
<session probability="100" name="jabber-digest" type="ts_jabber">
<!-- regexp captures stream ID returned by server -->
<request>
<dyn_variable name="sid" re="<stream:stream id="(.*)" xmlns:stream"/>
<jabber type="connect" ack="local"></jabber>
</request>
<thinktime value="2"></thinktime>
<transaction name="auth_digest">
<request> <jabber type="auth_get" ack="local"></jabber> </request>
<request subst="true"> <jabber type="auth_set_digest" ack="local"></jabber> </request>
</transaction>
...
</session>
sip-digest authentication
<session probability="100" name="jabber-sipdigest" type="ts_jabber">
<request> <jabber type="connect" ack="local"></jabber> </request>
<thinktime value="2"></thinktime>
<transaction name="auth_sipdigest">
<!-- regexp captures nonce value returned by server -->
<request>
<dyn_variable name="nonce"
re="<Nonce encoding="hex">(.*)<\/Nonce>"/>
<jabber type="auth_get" ack="local"></jabber>
</request>
<request subst="true"> <jabber type="auth_set_sip" ack="local"></jabber> </request>
</transaction>
...
</session>
There are two actions available to allow for rudimentary privacy lists load testing: