Tsung Document Description

First, the default code: UTF-8, you can modify as needed, such as
<?xml version= "1.0″encoding=" iso-8859-1″?>
II. structure of the XML file
First, the overall understanding of the structure of the XML file, which is made up of the following tags
2.1 Top Labels <tsung>
2.2 Client Tags <clients>
2.3 Service-Side tags <servers>
2.4 Monitoring Labels <monitor>
2.5 Load Tags <load>
2.6 Option Labels <options>
2.7 Process Labels <sessions>
Third, the top label:
1.1 Top labels are tsung, such as
<?xml version= "1.0″?>
<! DOCTYPE Tsung SYSTEM "/USR/SHARE/TSUNG/TSUNG-1.0.DTD" [] >
<tsung loglevel= "Info" >
...
</tsung>
1.2 Parameters:
1.2.1:dumptraffic
True: All communication will be recorded, note: This will greatly reduce the Tsung speed, which is generally used for debugging
Light: only 44 bytes before dumping
1.2.2:loglevel:
Emergency
Critical
Error
Warning (recommended)
Notice (default)
Info
Debug (if you need to look at the details, note: Use make debug to recompile Tsung when using this property)
Third, the client label and service-side tag (these two are related, need to understand)
3.1 Simple settings:
<clients>
<client host= "localhost" use_controller_vm= "true"/>
</clients>
<servers>
<server host= "127.0.0.1″port=" 80″type= "TCP" ></server>
</servers>
Note: The most basic settings are on the same machine.
3.2 Advanced Settings:
<clients>
<client host= "Louxor" weight= "1″maxusers=" 800″>
<ip value= "10.9.195.12″></ip>
<ip value= "10.9.195.13″></ip>
</client>
<client host= "Memphis" weight= "3″maxusers=" 600″cpu= "2″/>
</clients>
<servers>
<server host= "10.9.195.1″port=" 8080″type= "TCP" ></server>
</servers>
Multiple virtual IPs can be used to simulate more machines, which is useful when the load balancer uses client IPs to distribute traffic to the server cluster.
In this example, the second machine in the Tsung cluster, it is set to a higher proportion, two CPUs. It uses two Erlang virtual machines to make the most of the CPU.
Note: Even though Erlang VMS can now handle multiple CPUs (Erlang SMP), the test shows that a single CPU is more efficient for a Tsung client than a single VM. So you have the best number of CPUs to be equal to your node count. If you also insist on using Erlang SMP, start Tsung with the-s option, and do not set the number of CPUs in the configuration file.
By default, the load is uniformly distributed to all CPUs (the default is one client, one CPU). The weight of the parameter can be used to measure the processing speed of the client machine. For example, there are two real machines, one with a specific gravity of 1 and the other 2, so the second machine will be more user-1/3,2/3 than the first machine. In the example above, the second machine has 2 CPU weighting of 3, which is equivalent to 1.5 of each CPU's weight.
The parameter maxusers is used to ignore the limit on the number of sockets opened by a single process (default is 1024). When the number of users is higher than this limit, a new VM is started to process the new user. The default value for parameter maxusers is 800. Now that the machine turns on the kernel poll function, you can set a maximum value for the maxusers (such as 30000) without a performance penalty (but be careful not to forget to use ulimit-n to increase the OS limit [this is not clear]),
3.3 Running a tsung[with job scheduler does not understand]
Original in document 6.2.3
Iv. Monitoring Label
Tsung monitors multiple remote servers, each of which is backed up by multiple interactions with remote agents. This can be configured in the <monitor> tab. Statistics can be counted: CPU usage, average workload, memory usage.
Note here: You can get monitoring nodes from the job debugger, such as:
<monitor batch= "true" host= "torque" type= "Erlang" ></monitor>
There are several types of remote proxies supported (by default, Erlang).
4.1
Five, load label
5.1 Randomly generated users
The load tag defines several user arrival stages
<load>
<arrivalphase phase= "1″duration=" 10″unit= "Minute" >
<users interarrival= "2″unit=" second "></users>
</arrivalphase>
<arrivalphase phase= "2″duration=" 10″unit= "Minute" >
<users interarrival= "1″unit=" second "></users>
</arrivalphase>
<arrivalphase phase= "3″duration=" 10″unit= "Minute" >
<users interarrival= "0.1″unit=" second "></users>
</arrivalphase>
</load>
The above configuration file indicates that the user's generation is divided into three stages, the first phase, a new user is generated every 2 seconds, and the second phase, a new user is generated per second, and the third phase generates 10 new users per second. These tests will be completed after all users have finished their process (the procedure represented by the session label later).
The third stage above is the generation of 10 users per second, but it is literally understood to generate a user every 0.1 seconds, you can also implement the same function in another way, using arrivalrate instead of arrivalphase, for example:
<arrivalphase phase= "1″duration=" 10″unit= "Minute" >
<users arrivalrate= "10″unit=" second "></users>
</arrivalphase>
You can also use the Loop property in the load tag to make the entire process run multiple times, such as: loop= ' 2′ means that the sequence is looped two times, so the load is executed three times a day. (This will be available after version 1.2.2)
The load is determined by the number of HTTP requests per second and the number of request per session, for example: each session has 100 request and 10 new users per second, so the average throughput of the theory is 1000 request per second.
5.2 Static Build User
You want to start a given session at a specified time during the test, and your wish will be implemented after the 1.3.1 version.
<load>
<arrivalphase phase= "1″duration=" 10″unit= "Minute" >
<users interarrival= "2″unit=" second "></users>
</arrivalphase>
<user session= "Http-example" Start_time= "185″unit=" second "></user>
<user session= "Http-example" start_time= "10″unit=" Minute "></user>
<user session= "foo" start_time= "11″unit=" Minute "></user>
</load>
<sessions>
<session name= "Http-example" probability= "0″type=" Ts_http ">
<request> </session>
<session name= "foo" probability= "100″type=" Ts_http ">
<request> </session>
<sessions>
In this example, there are two sessions, one with a probability of "0" (so the first phase is not executed, that is, the user portion is randomly generated), and the other is 100. After the test started, we set 3 users to start each, the first in 3 minutes 5 seconds (perform http-example session) Start, the second after 10 minutes to start (http-example session), the last one in 11 minutes after the start (foo session).
5.3 The process of load testing
By default, Tsung ends after all users have completed their session, so this is much longer than the user-generated process. If you want to stop Tsung regardless of whether the stage is complete or not, whether or not the session is active. Then you can add the duration attribute in the load tag (valid after version 1.3.2).
<load duration= "1″unit=" Hour ">
<arrivalphase phase= "1″duration=" 10″unit= "Minute" >
<users interarrival= "2″unit=" second "></users>
</arrivalphase>
</load>
The current maximum value is 50 days, and the unit can be "second", "Minute", "hour".
VI. option Tags:
The default value of the global variable can be set here, for example: think time between two requests in the scene, SSL encryption algorithm, TCP/UDP cache size (default is 32K). If override is set to True, these values will overwrite the corresponding values in the session configuration file.
<option name= "ThinkTime" value= "3″random=" false "override=" true "/>
<option name= "Ssl_ciphers" value= "Exp1024-rc4-sha,edh-rsa-des-cbc3-sha"/>
<option name= "Tcp_snd_buffer" value= "16384″></option>
<option name= "Tcp_rcv_buffer" value= "16384″></option>
<option name= "Udp_snd_buffer" value= "16384″></option>
<option name= "Udp_rcv_buffer" value= "16384″></option>
Note: After 1.3.1, add an attribute--hibernate, which is used to reduce the memory consumption of the impersonated user in the think time. By default, hibernate is activated when the think time is more than 10s, which can be modified such as:
<option name= "Hibernate" value= "5″></option>
To disable hibernate, set the value to "infinity"
6.1xmpp/jabber Options
Temporary ...
6.2http Options
For HTTP, you can set the value of UserAgent [after version 1.1.0] and have a probability attribute for each user_agent (all probability values are 100), such as:
<option type= "ts_http" name= "User_agent" >
<user_agent probability= "80″>
mozilla/5.0 (X11; U Linux i686; En-us; rv:1.7.8) gecko/20050513 galeon/1.3.21
</user_agent>
<user_agent probability= "20″>
mozilla/5.0 (Windows; U Windows NT 5.2; FR-FR; rv:1.7.8) gecko/20050511 firefox/1.0.4
</user_agent>
</option>

Seven, session label
The session defines the scene itself, which describes the request to be run.
Each session has a specified probality attribute, which is used to determine which session a new user is running, and the probability property of all sessions is 100.
A transaction is a way of manually counting data. For example, if you want to know the response time of your website login page, you need to put all the requests (HTML and embedded images) of this page into this transaction. In the example below you will see the transaction statistics and reports called Index_request. It is important to note that if think time is part of the request, you also need to add think time to the transaction.
7.1. Think time
You can assign a fixed or random think time to each individual request, by default, the random think time is the exponential distribution based on value
<thinktime value= "20″random=" true "></thinktime>
Think time here is a 20-based exponential distribution.
The 1.3.0 version also adds a range of controls that can set a maximum minimum value, which fluctuates between the maximum and minimum values at random times.
<thinktime min= "2″max=" 10″random= "true" ></thinktime>
7.2. HTTP protocol
The following example shows the various features of the HTTP protocol: GET, POST request, Basic authentication, transaction, data statistic definition, status request (if modified since)
<sessions>
<session name= "Http-example" probability= "70″type=" Ts_http ">
<request>
</request>
<thinktime value= "20″random=" true "></thinktime>
<transaction name= "Index_request" >
<request>
<request>
</request>
<request>
<www_authenticate userid= "Aladdin" passwd= "open sesame"/>
</request>
</session>
<session name= "BackOffice" probability= "30″...>
... </session>
</sessions>
After the 1.2.2 version, you can also add any HTTP headers like this:
<request>
<www_authenticate userid= "Aladdin" passwd= "open sesame"/>
</request>
In version 1.3.0 you can read the post and put contents from an external file.
After version 1.3.1, you can also manually set a cookie, because the cookie is not durable, so you have to add a code to each request
<add_cookie key= "foo" value= "Bar"/>
<add_cookie key= "id" value= "123″/>
7.3~7.7 Temporary Brief

Eight, Advanced Configuration
8.1, dynamically replace
8.2, read external file
8.3, dynamic variable
8.4, check server response
8.5, loop, select (loop,if)
after the 1.3.0 version, you can add conditional/non-conditional loops:
8.5.1, <for>:
From: Initial value
to: Final value
incr: Increment
var: save variable name when numeric value
<for from= "1″to=" 10″incr= "1″var= "Counter";
[...]
<request> [...]
</for>
8.5.2, <repeat>
Name: Loop name
Max_repeat: Number of cycles
Note: The last label of the loop is <while> or < Until>
<repeat name= "Myloop" max_repeat= "40″>
[...]
<request>
<dyn_variable name= "result" regexp= "Result: (. *)"/>
<request> </if>
You can use EQ or NEQ to check for variables

Ix. Statistics and reports
9.1, available properties
Request: Requested time per request
Page: Request time for a series of requests (a page is a series of requests that do not contain "think Times"
Connect: The process of connection creation
Reconnect: Number of reconnection
SIZE_RCV: The size of the reaction (in bytes)
Size_sent: The requested size (in bytes)
Session: Duration of a user session
Users: Number of synchronized users
connected: number of simultaneous connected users
Custom transaction:
9.2, design
9.3 Generate report
First log log directory for your test ("~/.tsung/log/ yyyymmdd-hhmm/"), then proceed to the console, execute:" tsung_stats.pl "(full command/usr/lib/tsung/bin/tsung_stats.pl)
You can even generate statistics when the test runs.
Use-help to see all the mutable options:
9.4tsung Summary
Available options:
[--help] (This help text)
[--verbose]
[-- Debug]
[--noplot] (don ' t make graphics)
[--gnuplot <command>] (path to the gnuplot binary)
[--nohtml] ( Don ' t create HTML reports)
[--logy] (Logarithmic scale for Y axis)
[--tdir <template_dir>] (Path to the HTML t Sung templates)
[--noextra (Don t generate graphics from extra data (OS monitor, etc)
[--stats <file>] (stats File to analyse, Default=tsung.log)

9.5 Graphics Overview
Can view the attachment 20110531-10:33.tar.gz (this is the compressed package of my own running file)
9.6tsung Drawing
9.7RRD

Transferred from: http://blog.programfan.info/tsung/178.jsp

Tsung Document Description