字数:0 关键词: 测试工具

Tsung Documentation Release 1.5.1 Nicolas Niclausse April 09, 2014 CONTENTS 1 Introduction 3 1.1 What is Tsung?..............................................3 1.2 What is Erlang and why is it important for Tsung?...........................3 1.3 Tsung background............................................3 2 Features 5 2.1 Tsung main features...........................................5 2.2 HTTP related features..........................................5 2.3 WEBDAV related features........................................6 2.4 Jabber/XMPP related features......................................6 2.5 PostgreSQL related features.......................................6 2.6 MySQL related features.........................................7 2.7 Websocket related features........................................7 2.8 AMQP related features..........................................7 2.9 MQTT related features..........................................7 2.10 LDAP related features..........................................7 2.11 Complete reports set...........................................7 2.12 Highlights................................................8 3 Installation 9 3.1 Dependencies...............................................9 3.2 Compilation...............................................9 3.3 Configuration............................................... 10 3.4 Running................................................. 10 3.5 Feedback................................................. 10 4 Benchmark Approach 11 4.1 HTTP/WebDAV............................................. 11 4.2 LDAP................................................... 12 4.3 PostgreSQL................................................ 12 4.4 MySQL.................................................. 12 4.5 Jabber/XMPP............................................... 12 5 Using the proxy recorder 15 5.1 PostgreSQL................................................ 15 5.2 HTTP and WEBDAV.......................................... 15 6 Understanding tsung.xml configuration file 17 6.1 File structure............................................... 17 6.2 Clients and server............................................ 18 i 6.3 Monitoring................................................ 20 6.4 Defining the load progression...................................... 21 6.5 Setting options.............................................. 23 6.6 Sessions................................................. 25 6.7 Advanced Features............................................ 44 7 Statistics and Reports 55 7.1 File format................................................ 55 7.2 Available stats.............................................. 56 7.3 Design.................................................. 57 7.4 Generating the report........................................... 57 7.5 Tsung summary............................................. 57 7.6 Graphical overview............................................ 59 7.7 Tsung Plotter............................................... 59 7.8 RRD................................................... 59 8 References 63 9 Acknowledgments 65 10 Frequently Asked Questions 67 10.1 Can’t start distributed clients: timeout error............................... 67 10.2 Tsung crashes when I start it....................................... 68 10.3 Why do i have error_connect_emfile errors?............................... 68 10.4 Tsung still crashes/fails when I start it!................................. 69 10.5 Can I dynamically follow redirect with HTTP?............................. 69 10.6 What is the format of the stats file tsung.log?.............................. 69 10.7 How can I compute percentile/quartiles/median for transactions or requests response time?...... 70 10.8 How can I specify the number of concurrent users?........................... 71 10.9 SNMP monitoring doesn’t work?!.................................... 71 10.10 How can i simulate a fix number of users?................................ 71 11 Errors list 73 11.1 error_closed............................................... 73 11.2 error_inet_...................................... 73 11.3 error_unknown_data........................................... 73 11.4 error_unknown_msg........................................... 73 11.5 error_unknown.............................................. 73 11.6 error_repeat_..................................... 73 11.7 error_send_...................................... 73 11.8 error_send................................................ 74 11.9 error_connect_.................................... 74 11.10 error_no_online............................................. 74 11.11 error_no_offline............................................. 74 11.12 error_no_free_userid........................................... 74 11.13 error_next_session............................................ 74 11.14 error_mysql_......................................... 74 11.15 error_mysql_badpacket......................................... 74 11.16 error_pgsql................................................ 74 12 Changelog 75 13 tsung-1.0.dtd 85 14 Indices and tables 95 ii Index 97 iii iv Tsung Documentation, Release 1.5.1 Everything you need to know about Tsung About Tsung Tsung is a high-performance benchmark framework for various protocols including HTTP, XMPP, LDAP, etc • Website: tsung.erlang-projects.org • Source code: github.com/processone/tsung • Bugtracker: Jira CONTENTS 1 Tsung Documentation, Release 1.5.1 2 CONTENTS CHAPTER ONE INTRODUCTION 1.1 What is Tsung? Tsung (formerly IDX-Tsunami) is a distributed load testing tool. It is protocol-independent and can currently be used to stress HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and Jabber/XMPP servers. It is distributed under the GNU General Public License version 2. 1.2 What is Erlang and why is it important for Tsung? Tsung’s main strength is its ability to simulate a huge number of simultaneous user from a single machine. When used on cluster, you can generate a really impressive load on a server with a modest cluster, easy to set-up and to maintain. You can also use Tsung on a cloud like EC2. Tsung is developed in Erlang and this is where the power of Tsung resides. Erlang is a concurrency-oriented programming language. Tsung is based on the Erlang OTP (Open Transaction Platform) and inherits several characteristics from Erlang: Performance Erlang has been made to support hundred thousands of lightweight processes in a single virtual ma- chine. Scalability Erlang runtime environment is naturally distributed, promoting the idea of process’s location transparency. Fault-tolerance Erlang has been built to develop robust, fault-tolerant systems. As such, wrong answer sent from the server to Tsung does not make the whole running benchmark crash. More information on Erlang on http://www.erlang.org. 1.3 Tsung background History: • Tsung development was started by Nicolas Niclausse in 2001 as a distributed jabber load stress tool for internal use at http://IDEALX.com/ (now OpenTrust). It has evolved as an open-source multi-protocol load testing tool several months later. The HTTP support was added in 2003, and this tool has been used for several industrial projects. It is now hosted by Erlang-projects, and supported by http://process-one.net/. The list of contributors is available in the source archive at https://github.com/processone/tsung/blob/master/CONTRIBUTORS and at https://github.com/processone/tsung/graphs/contributors. 3 Tsung Documentation, Release 1.5.1 • It is an industrial strength implementation of a stochastic model for real users simulation. User events distribu- tion is based on a Poisson Process. More information on this topic in: Z. Liu, N. Niclausse, and C. Jalpa-Villanueva. Traffic Model and Performance Evaluation of Web Servers. Performance Evaluation, Volume 46, Issue 2-3, October 2001. • This model has already been tested in the INRIA WAGON research prototype (Web trAffic GeneratOr and beNchmark). WAGON was used in the http://www.vthd.org/ project (Very High Broadband IP/WDM test plat- form for new generation Internet applications, 2000-2004). Tsung has been used for very high load tests: • Jabber/XMPP protocol: – 90,000 simultaneous Jabber users on a 4-node Tsung cluster (3xSun V240 + 1 Sun V440). – 10,000 simultaneous users. Tsung was running on a 3-computers cluster (CPU 800MHz). • HTTP and HTTPS protocol: – 12,000 simultaneous users. Tsung were running on a 4-computers cluster (in 2003). The tested platform reached 3,000 requests per second. – 10 million simultaneous users running on a 75-computers cluster, generating more than one million re- quests per second. Tsung has been used at: • DGI (Direction Générale des impôts): French finance ministry • Cap Gemini Ernst & Young • IFP (Institut Français du Pétrole): French Research Organization for Petroleum • LibertySurf • Sun (TM) for their Mooddlerooms platform on Niagara processors: https://blogs.oracle.com/kevinr/resource/Moodle-Sun-RA.pdf 4 Chapter 1. Introduction CHAPTER TWO FEATURES 2.1 Tsung main features • High Performance: Tsung can simulate a huge number of simultaneous users per physical computer: It can simulates thousands of users on a single CPU (Note: a simulated user is not always active: it can be idle during a thinktime period). Traditional injection tools can hardly go further than a few hundreds (Hint: if all you want to do is requesting a single URL in a loop, use ab; but if you want to build complex scenarios with extended reports, Tsung is for you). • Distributed: the load can be distributed on a cluster of client machines • Multi-Protocols using a plug-in system: HTTP (both standard web traffic and SOAP), WebDAV, Jabber/XMPP and PostgreSQL are currently supported. LDAP and MySQL plugins were first included in the 1.3.0 release. • SSL support • Several IP addresses can be used on a single machine using the underlying OS IP Aliasing • OS monitoring (CPU, memory and network traffic) using Erlang agents on remote servers or SNMP • XML configuration system: complex user’s scenarios are written in XML. Scenarios can be written with a simple browser using the Tsung recorder (HTTP and PostgreSQL only). • Dynamic scenarios: You can get dynamic data from the server under load (without writing any code) and re- inject it in subsequent requests. You can also loop, restart or stop a session when a string (or regexp) matches the server response. • Mixed behaviours: several sessions can be used to simulate different type of users during the same benchmark. You can define the proportion of the various behaviours in the benchmark scenario. • Stochastic processes: in order to generate a realistic traffic, user thinktimes and the arrival rate can be random- ized using a probability distribution (currently exponential) 2.2 HTTP related features • HTTP/1.0 and HTTP/1.1 support • GET, POST, PUT, DELETE, HEAD, OPTIONS and PATCH requests • Cookies: Automatic cookies management (but you can also manually add more cookies) • ‘GET If-modified since’ type of request • WWW-authentication Basic and Digest. OAuth 1.0 5 Tsung Documentation, Release 1.5.1 • User Agent support • Any HTTP Headers can be added • Proxy mode to record sessions using a Web browser • SOAP support using the HTTP mode (the SOAPAction HTTP header is handled). • HTTP server or proxy server load testing. 2.3 WEBDAV related features The WebDAV (RFC 4918) plugin is a superset of the HTTP plugin. It adds the following features (some versionning extensions to WebDAV (RFC 3253) are also supported): • Methods implemented: DELETE, CONNECT, PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK, MKCOL, REPORT, OPTIONS, MKACTIVITY, CHECKOUT, MERGE • Recording of DEPTH, IF, TIMEOUT OVERWRITE, DESTINATION, URL and LOCK-TOKEN Headers. 2.4 Jabber/XMPP related features • Authentication (plain-text, digest and sip-digest). STARTTLS • presence and register messages • Chat messages to online or offline users • MUC: join room, send message in room, change nickname • Roster set and get requests • Global users’ synchronization can be set on specific actions • BOSH & XMPP over Websocket • raw XML messages • PubSub • Multiple vhost instances supported • privacy lists: get all privacy list names, set list as active 2.5 PostgreSQL related features • Basic and MD5 Authentication • Simple Protocol • Extended Protocol (new in version 1.4.0 ) • Proxy mode to record sessions 6 Chapter 2. Features Tsung Documentation, Release 1.5.1 2.6 MySQL related features This plugin is experimental. It works only with MySQL version 4.1 and higher. • Secured Authentication method only (MySQL >= 4.1) • Basic Queries 2.7 Websocket related features This plugin is experimental. It only supports RFC 6455 currently. For used as a server type, it works like other transport protocol like tcp and udp, any application specific protocol data can be send on it. You can find examples used as session type in examples/websocket.xml. • Both as a server type and session type 2.8 AMQP related features This plugin is experimental. It only supports AMQP-0.9.1 currently. You can find examples in examples/amqp.xml. • Basic publish and consume • Publisher confirm and consumer ack • QoS 2.9 MQTT related features This plugin is experimental. It supports MQTT V3.1. You can find examples in examples/mqtt.xml. • Connect to mqtt broker with options • Publish mqtt messages to the broker • Subscribe/unsubscribe topics • Support QoS 0 and QoS 1 2.10 LDAP related features • Bind • Add, modify and search queries • Starttls 2.11 Complete reports set Measures and statistics produced by Tsung are extremely feature-full. They are all represented as a graphic. Tsung produces statistics regarding: 2.6. MySQL related features 7 Tsung Documentation, Release 1.5.1 • Performance: response time, connection time, decomposition of the user scenario based on request grouping instruction (called transactions), requests per second • Errors: Statistics on page return code to trace errors • Target server behaviour: An Erlang agent can gather information from the target server(s). Tsung produces graphs for CPU and memory consumption and network traffic. SNMP and munin is also supported to monitor remote servers. par Note that Tsung takes care of the synchronization process by itself. Gathered statistics are «synchronized». It is possible to generate graphs during the benchmark as statistics are gathered in real-time. 2.12 Highlights Tsung has several advantages over other injection tools: • High performance and distributed benchmark: You can use Tsung to simulate tens of thousands of virtual users. • Ease of use: The hard work is already done for all supported protocol. No need to write complex scripts. Dynamic scenarios only requires small trivial piece of code. • Multi-protocol support: Tsung is for example one of the only tool to benchmark SOAP applications • Monitoring of the target server(s) to analyze the behaviour and find bottlenecks. For example, it has been used to analyze cluster symmetry (is the load properly balanced ?) and to determine the best combination of machines on the three cluster tiers (Web engine, EJB engine and database) 8 Chapter 2. Features CHAPTER THREE INSTALLATION This package has been tested on Linux, FreeBSD and Solaris. A port is available on Mac OS X. It should work on Erlang supported platforms (Linux, Solaris, *BSD, Win32 and Mac OS X). On Mac OS X you can install Tsung via Homebrew (http://brew.sh/): brew install tsung. 3.1 Dependencies • Erlang/OTP R13B and up (download). Erlang is now part of Fedora and Debian/Ubuntu repositories. • pgsql module made by Christian Sunesson (for the PostgreSQL plugin): sources available at http://jungerl.sourceforge.net/ . The module is included in the source and binary distribution of Tsung. It is released under the EPL License. • mysql module made by Magnus Ahltorp & Fredrik Thulin (for the mysql plugin): sources available at http://www.stacken.kth.se/projekt/yxa/. The modified module is included in the source and binary distribution of Tsung. It is released under the three-clause BSD License. • eldap module (for the LDAP plugin): sources available at http://jungerl.sourceforge.net/. The module is in- cluded in the source and binary distribution of Tsung. It is released under the GPL License. • mochiweb libs (for XPath parsing, optionally used for dynamic variables in the HTTP plugin): sources available at https://github.com/mochi/mochiweb. The module is included in the source and binary distribution of Tsung. It is released under the MIT License. • gnuplot and perl5 (optional; for graphical output with tsung_stats.pl script). The Template Toolkit is used for HTML reports (see http://template-toolkit.org/). • python and mathplotlib (optional; for graphical output with tsung-plotter). • for distributed tests, you need SSH access to remote machines without password (use a RSA/DSA key without passphrase or ssh-agent). Alternatively rsh is also supported. • bash 3.2 Compilation To compile Tsung, just download the latest version from http://tsung.erlang-projects.org/dist/ and run: ./configure make make install 9 Tsung Documentation, Release 1.5.1 If you want to download the latest development version, use git: git clone https://github.com/processone/tsung.git, see also https://github.com/processone/tsung. You can also build packages with make deb (on Debian and Ubuntu) and make rpm (on Fedora, RHEL and other rpm based distribution). 3.3 Configuration The default configuration file is ~/.tsung/tsung.xml (there are several sample files in /usr/share/doc/tsung/examples). Log files are saved in ~/.tsung/log/. A new subdirectory is created for each test using the current date and time as name, e.g. ~/.tsung/log/20040217-0940. 3.4 Running Two commands are installed in the directory $PREFIX/bin: tsung and tsung-recorder. A man page is available for both commands. $ tsung -h Usage: tsung start|stop|debug|status Options: -f set configuration file (default is ~/.tsung/tsung.xml) (use - for standard input) -l set log directory (default is ~/.tsung/log/YYYYMMDD-HHMM/) -i set controller id (default is empty) -r set remote connector (default is ssh) -s enable erlang smp on client nodes -p set maximum erlang processes per vm (default is 250000) -m write monitoring output on this file (default is tsung.log) (use - for standard output) -F use long names (FQDN) for erlang nodes -w warmup delay (default is 10 sec) -v print version information and exit -6 use IPv6 for Tsung internal communications -h display this help and exit A typical way of using tsung is to run: tsung -f myconfigfile.xml start. The command will print the current log directory created for the test, and wait until the test is over. 3.5 Feedback Use the Tsung mailing list if you have suggestions or questions about Tsung. You can also use the bug tracker available at https://support.process-one.net/browse/TSUN. You can also try the #tsung IRC channel on Freenode. 10 Chapter 3. Installation CHAPTER FOUR BENCHMARK APPROACH 4.1 HTTP/WebDAV 4.1.1 Benchmarking a Web server 1. Record one or more sessions: start the recorder with: tsung-recorder start, and then configure your browser to use Tsung proxy recorder (the listen port is 8090). A session file will be created. For HTTPS recording, use http://- instead of https:// in your browser. 2. Edit / organize scenario, by adding recorded sessions in the configuration file. 3. Write small code for dynamic parts if needed and place dynamic mark-up in the scenario. 4. Test and adjust scenario to have a nice progression of the load. This is highly dependent of the application and of the size of the target server(s). Calculate the normal duration of the scenario and use the interarrival time between users and the duration of the phase to estimate the number of simultaneous users for each given phase. 5. Launch benchmark with your first application parameters setup: tsung start (run man tsung for more options). 6. Wait for the end of the test or stop by hand with tsung stop (reports can also be generated during the test (see Statistics and Reports): the statistics are updated every 10 seconds). For a brief summary of the current activity, use tsung status. 7. Analyze results, change parameters and relaunch another benchmark. 4.1.2 WebDAV It’s the same approach as HTTP: first you start to record one or more sessions with the recorder: tsung-recorder -p webdav start. 4.1.3 Benchmarking a proxy server 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: 11 Tsung Documentation, Release 1.5.1 4.2 LDAP 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. 4.3 PostgreSQL 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 To choose another port and/or address: tsung-recorder -L 5432 -I -P 5433 -p pgsql start. This will start a proxy listening to port 5432 and will proxy requests to 4.4 MySQL 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. 4.5 Jabber/XMPP 4.5.1 Overview This paragraph explains how to write a session for Jabber/XMPP. There are two differences between HTTP and Jabber testing: • There is no recorder for Jabber, so you have to write your sessions by hand. An example is provided in Jab- ber/XMPP. • The Jabber plugin does not parse XML; instead it uses packet acknowledgments. 4.5.2 Acknowledgments of messages 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 mes- sages. To do that, set a request with global ack (it can be the first presence msg: You also have to specify the number of users to be connected: 12 Chapter 4. Benchmark Approach Tsung Documentation, Release 1.5.1 To be sure that exactly global_number users are started, add the maxnumber attribute to users: If you do not specify maxnumber, the global ack will be reset every global_number users. Bidirectional Presence New in 1.2.2: This version adds an new option for a session. if you set the attribute bidi (for bidirectional) in the tag: , then incoming messages from the server will be analyzed. Currently, only roster subscription requests are handled: if a user received a subscription request (), it will respond with a message. Status: Offline, Connected and Online 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: • It removes the client from the list of Online users, and moves them into the list of Connected users. • It sends a broadcast presence update of type="unavailable". 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. 4.5.3 Authentication 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: ... • digest authentication as described in XMPP JEP-0078: Non-SASL Authentication http://www.jabber.org/jeps/jep-0078.html 4.5. Jabber/XMPP 13 Tsung Documentation, Release 1.5.1 ... • sip-digest authentication ... 4.5.4 Privacy list testing There are two actions available to allow for rudimentary privacy lists load testing: • privacy:get_names gets the list of all names .. of privacy lists stored by the server for a given user • privacy:set_active sets a list with a predefined name as active. The list name is determined from the JID, e.g. if the user’s JID is “john@average.com” then the list name is “john@average.com_list”. One should take care of properly seeding the server database in order to ensure that such a list exists. 14 Chapter 4. Benchmark Approach CHAPTER FIVE USING THE PROXY RECORDER The recorder has three plugins: for HTTP, WebDAV and for PostgreSQL. To start it, run tsung-recorder -p start, where PLUGIN can be http, webdav or pgsql for PostgreSQL. The default plugin is http. The proxy is listening to port 8090. You can change the port with -L portnumber. To stop it, use tsung-recorder stop. The recorded session is created as ~/.tsung/tsung_recorderYYYMMDD-HH:MM.xml; if it doesn’t work, take a look at ~/.tsung/log/tsung.log-tsung_recorder@hostname During the recording, you can add custom tag in the XML file, this can be useful to set transactions or comments: tsung-recorder record_tag “’‘ Once a session has been created, you can insert it in your main configuration file, either by editing by hand the file, or by using an ENTITY declaration, like: ]> ... &mysession1; 5.1 PostgreSQL For PostgreSQL, the proxy will connect to the server at IP and port 5432. Use -I serverIP to change the IP and -P portnumber to change the port. 5.2 HTTP and WEBDAV For HTTPS recording, use http://- instead of https:// in your browser New in 1.2.2: For HTTP, you can configure the recorder to use a parent proxy (but this will not work for https). Add the -u option to enable parent proxy, and use -I serverIP to set the IP and -P portnumber to set the port of the parent. 15 Tsung Documentation, Release 1.5.1 16 Chapter 5. Using the proxy recorder CHAPTER SIX UNDERSTANDING TSUNG.XML CONFIGURATION FILE 6.1 File structure The default encoding is utf-8. You can use a different encoding, like in: Scenarios are enclosed into tsung tags: ... If you add the attribute dumptraffic=”true”, all the traffic will be logged to a file. Warning: this will considerably slow down Tsung, so use with care. It is useful for debugging purpose. You can use the attribute dumptraffic=”light” to dump only the first 44 bytes. Since version 1.4.0, you have also a specific logging per protocol, using dumptraffic=”protocol”. It’s currently only implemented for HTTP: this will log all requests in a CSV file, with the following data: #date;pid;id;http method;host;URL;HTTP status;size;duration;transaction;match;error;tag Where: field description date timestamp at the end of the request (seconds since 1970-01-01 00:00:00 UTC) pid erlang process id id tsung user id host server hostname url URL (relative) HTTP status HTTP reponse status (200, 304, etc.) size reponse size (in bytes) duration request duration (msec) transaction name of the transaction (if any) this request was made in match if a match is defined in the request: match|nomatch (last if several are defined) error name of http error (or empty) tag tag name if the request was tagged; empty otherwise 17 Tsung Documentation, Release 1.5.1 The loglevel can also have a great impact on performance: For high load, warning is recommended. Possible values are: • emergency • critical • error • warning • notice (default) • info • debug For REALLY verbose logging, recompile tsung with make debug and set loglevel to debug. 6.2 Clients and server Scenarios start with clients (Tsung cluster) and server definitions: 6.2.1 Basic setup For non distributed load, you can use a basic setup like: This will start the load on the same host and on the same Erlang virtual machine as the controller. The server is the entry point into the cluster. You can add several servers, by default each server will have a weight of 1, and each session will choose a server randomly according to the weight. You can set a weight for each server like this (weight can be an integer or a float): (in version older than 1.5.0, the weight option was not implemented and a round robin algorithm was used to choose the server). Type can be tcp, ssl, udp (for IPv6, use tcp6, ssl6 or udp6 ; only available in version 1.4.2 and newer) or websocket (only available in version 1.5.0 and newer)) 6.2.2 Advanced setup The next example is more complex, and use several features for advanced distributed testing: 18 Chapter 6. Understanding tsung.xml configuration file Tsung Documentation, Release 1.5.1 Several virtual IP can be used to simulate more machines. This is very useful when a load-balancer use the client’s IP to distribute the traffic among a cluster of servers. New in 1.1.1: IP is no longer mandatory. If not specified, the default IP will be used. New in 1.4.0: You can use to scan for all the IP aliases on a given interface (eth0 in this example). In this example, a second machine is used in the Tsung cluster, with a higher weight, and 2 cpus. Two Erlang virtual machines will be used to take advantage of the number of CPU. Note: Even if an Erlang VM is now able to handle several CPUs (erlang SMP), benchmarks shows that it’s more efficient to use one VM per CPU (with SMP disabled) for tsung clients. Only the controller node is using SMP erlang. Therefore, cpu should be equal to the number of cores of your nodes. If you prefer to use erlang SMP, add the -s option when starting tsung (and don’t set cpu in the config file). By default, the load is distributed uniformly on all CPU (one CPU per client by default). The weight parameter (integer) can be used to take into account the speed of the client machine. For instance, if one real client has a weight of 1 and the other client has a weight of 2, the second one will start twice the number of users as the first (the proportions will be 1/3 and 2/3). In the earlier example where for the second client has 2 CPU and weight=3, the weight is equal to 1.5 for each CPU. maxusers The maxusers parameter is used to bypass the limit of maximum number of sockets opened by a single process (1024 by default on many OS) and the lack of scalability of the select system call. When the number of users is higher than the limit, a new erlang virtual machine will be started to handle new users. The default value of maxusers is 800. Nowadays, with kernel polling enable, you can and should use a very large value for maxusers (30000 for example) without performance penalty (but don’t forget to raise the limit of the OS with ulimit -n, see also Why do i have error_connect_emfile errors?). Note: If you are using a tsung master with slaves, the master distributes sessions to slaves. If a session contains multiples requests, a slave will execute each of these requests in order. 6.2.3 Running Tsung with a job scheduler Tsung is able to get its client node list from a batch/job scheduler. It currently handle PBS/torque, LSF and OAR. To do this, set the type attribute to batch, e.g.: If you need to scan IP aliases on nodes given by the batch scheduler, use scan_intf like this: 6.2. Clients and server 19 Tsung Documentation, Release 1.5.1 6.3 Monitoring Tsung is able to monitor remote servers using several backends that communicates with remote agent. This is config- ured in the section. Available statistics are: CPU activity, load average and memory usage. Note that you can get the nodes to monitor from a job scheduler, like: Several types of remote agents are supported (erlang is the default): 6.3.1 Erlang The remote agent is started by Tsung. It use erlang communications to retrieve statistics of activity on the server. For example, here is a cluster monitoring definition based on Erlang agents, for a cluster of 6 computers: Note: monitored computers needs to be accessible through the network, and erlang communications must be allowed (no firewall is better). SSH (or rsh) needs to be configured to allow connection without password on. You must use the same version of Erlang/OTP on all nodes otherwise it may not work properly! If you can’t have erlang installed on remote servers, you can use one of the other available agents. New in version 1.5.1. erlang monitoring includes now an option to monitor a mysql db with mysqladmin. Use it like this: Availabe stats: number of mysql threads and Questions (queries) 6.3.2 SNMP The type keyword snmp can replace the erlang keyword, if SNMP monitoring is preferred. They can be mixed. Since version 1.2.2, you can customize the SNMP version, community and port number. It uses the Management Information Base (MIB) provided in net-snmp (see also SNMP monitoring doesn’t work?!). 20 Chapter 6. Understanding tsung.xml configuration file Tsung Documentation, Release 1.5.1 The default version is v1, default community public and default port 161. Since version 1.4.2, you can also customize the object identifiers (OID) retrieved from the SNMP server, using one or several oid element: type can be sample, counter or sum, and optionally you can define a function (with erlang syntax) to be applied to the value (eval attribute). 6.3.3 Munin New in version 1.3.1. Tsung is able to retrieve data from a munin-node agent (see http://munin- monitoring.org/wiki/munin-node). The type keyword must be set to munin, for example: 6.4 Defining the load progression 6.4.1 Randomly generated users The load progression is set-up by defining several arrival phases: With this setup, during the first 10 minutes of the test, a new user will be created every 2 seconds, then during the next 10 minutes, a new user will be created every second, and for the last 10 minutes, 10 users will be generated every second. The test will finish when all users have ended their session. You can also use arrivalrate instead of interarrival. For example, if you want 10 new users per second, use: You can limit the number of users started for each phase by using the maxnumber attribute, just like this: 6.4. Defining the load progression 21 Tsung Documentation, Release 1.5.1 In this case, only 100 users will be created in the first phases, and 200 more during the second phase. The complete sequence can be executed several times using the loop attribute in the load tag (loop=’2’ means the sequence will be looped twice, so the complete load will be executed 3 times) (feature available since version 1.2.2). The load generated in terms of HTTP requests / seconds will also depend on the mean number of requests within a session (if you have a mean value of 100 requests per session and 10 new users per seconds, the theoretical average throughput will be 1000 requests/ sec). New in version 1.5.1. You can also override the probability settings of sessions within a specific phase, using session_setup: 6.4.2 Statically generated users If you want to start a given session (see Sessions) at a given time during the test, it is possible since version 1.3.1: In this example, we have two sessions, one has a “0” probability (and therefore will not be used in the first phase), and the other 100%. We define 3 users starting respectively 3mn and 5 seconds after the beginning of the test (using the http-example session), one starting after 10 minutes, and a last one starting after 11 minutes (using the foo session this time) New in version 1.5.1. If you want to start several sessions at once, and if the name of these sessions starts with the same prefix, you can use a wildcard. Given the previous sessions, this example will start two users (one with foo session, and one with foobar session) at starttime +10s. 22 Chapter 6. Understanding tsung.xml configuration file Tsung Documentation, Release 1.5.1 6.4.3 Duration of the load test By default, tsung will end when all started users have finished their session. So it can be much longer than the duration of arrivalphases. If you want to stop Tsung after a given duration (even if phases are not finished or if some sessions are still actives), you can do this with the duration attribute in load (feature added in 1.3.2): Currently, the maximum value for duration is a little bit less than 50 days. unit can be second, minute or hour. 6.5 Setting options 6.5.1 Thinktimes, SSL, Buffers Default values can be set-up globally: thinktime between requests in the scenario, SSL cipher algorithms, TCP/UDP buffer sizes (the default value is 32KB). These values overrides those set in session configuration tags if override is true. 6.5.2 Timeout for acknowledgments of messages This is used to set the idle timeout(used for ‘parse’ and ‘local’ ack) and global ack timeout(used for ‘global’ ack). By default, idle timeout will be 10min(600000) and global ack timeout will be infinity. This value can be changed like this: 6.5.3 Hibernate New in version 1.3.1. The option hibernate is used to reduced memory consumption of simulated users during thinktimes. By default, hibernation will be activated for thinktimes higher than 10sec. This value can be changed like this: To disable hibernation, you must set the value to infinity. 6.5. Setting options 23 Tsung Documentation, Release 1.5.1 6.5.4 Rate_limit New in version 1.4.0. rate_limit. This will limit the bandwidth of each client (using a token bucket algorithm). The value is in KBytes per second. You can also specify a maximum burst value (eg. max=’2048’). By default the burst size is the same as the rate (1024KB in the following example). Currently, only incoming traffic is rate limited. 6.5.5 Ports_range If you need to open more than 30000 simultaneous connections on a client machine, you will be limited by the number of TCP client ports, even if you use several IPs (this is true at least on Linux). To bypass this limit, Tsung must not delegate the selection of client ports and together with using several IP for each client, you have to defined a range for available clients ports, for ex: 6.5.11 AMQP options You can set the AMQP heartbeat timeout; for example to set it to 30s (default is 600s), add: ... Only the incoming traffic is rate limited currently. 6.7.7 Requests exclusion New in version 1.5.1. It is possible to exclude some request for a special run. To do this you have to tag them and use the option -x when launching the run. For example, to exclude the GET of foo.png, add a tag to the respective request: Then launch the run with: 52 Chapter 6. Understanding tsung.xml configuration file Tsung Documentation, Release 1.5.1 tsung -f SCENARIO.xml -x image start Only the GET to / will be performed. Note that request tags also get logged on dumptraffic=”protocol” (see File structure) 6.7.8 Client certificate New in version 1.5.1. It is possible to use a client certificate for ssl authentication. You can use dynamic variables to set some parameters of the certificate (and the key password is optional). 6.7. Advanced Features 53 Tsung Documentation, Release 1.5.1 54 Chapter 6. Understanding tsung.xml configuration file CHAPTER SEVEN STATISTICS AND REPORTS 7.1 File format By default, Tsung use its own format (see FAQ What is the format of the stats file tsung.log?). Since version 1.4.2, you can configure Tsung to use a JSON format; however in this case, the tools tsung_stats.pl and tsung_plotter will not work with the JSON files. To enable JSON output, use: Example output file with JSON: { "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}, {"name":"freemem","hostname":"requiem","value":1,"mean": 2249.32421875,"stddev":0,"max": 2249.32421875,"min": 2249.32421875,"global_mean":0,"global_count":0}, {"name":"cpu","hostname":"requiem","value":1,"mean": 4.790419161676647,"stddev":0,"max": 4.790419161676647,"min": 4.790419161676647,"global_mean":0,"global_count":0}, {"name":"session","value":1,"mean": 387.864990234375,"stddev": 0,"max": 387.864990234375,"min": 387.864990234375 ,"global_mean":0,"global_count":0}, {"name":"users_count","value":1,"total":1}, {"name":"finish_users_count","value":1,"total":1}, {"name":"request","value":5,"mean": 75.331787109375,"stddev": 46.689242405019954,"max": 168.708984375,"min": 51.744873046875 ,"global_mean":0,"global_count":0}, {"name":"page","value":1,"mean": 380.7548828125,"stddev": 0.0,"max": 380.7548828125,"min": 380.7548828125,"global_mean": 0,"global_count":0}, {"name":"connect","value":1,"mean": 116.70703125,"stddev": 55 Tsung Documentation, Release 1.5.1 0.0,"max": 116.70703125,"min": 116.70703125,"global_mean":0 ,"global_count":0}, {"name":"size_rcv","value": 703,"total": 703}, {"name":"size_sent","value": 1083,"total": 1083}, {"name":"connected","value":0,"max":0}, {"name":"http_304","value":5,"total":5}]}]} 7.2 Available stats • request Response time for each request. • page Response time for each set of requests (a page is a group of request not separated by a thinktime). • 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 finished). • connected number of users with an opened TCP/UDP connection (example: for HTTP, during a think time, the TCP connection can be closed by the server, and it won’t be reopened until the thinktime has expired). new in 1.2.2. • custom transactions The mean response time (for requests, page, etc.) is computed every 10 sec (and reset). That’s why you have the highest mean and lowest mean values in the Stats report. Since version 1.3.0, the mean for the whole test is also computed. 7.2.1 HTTP specific stats: • counter for each response status (200, 404, etc.) 7.2.2 Jabber specific stats: • request_noack Counter of no_ack requests. Since response time is meaningless with no_ack requests, we keep a separate stats for this. new in 1.2.2. • async_unknown_data_rcv Only if bidi is true for a session. counter the number of messages received from the server without doing anything. new in 1.2.2. • async_data_sent Only if bidi is true for a session. Count the number of messages sent to the server in response of a message received from the server. new in 1.2.2. 7.2.3 OS monitoring stats: •{load,} System load average during the last minute •{cpu,} Free Memory 7.3 Design A bit of explanation on the design and internals of the statistics engine: Tsung was designed to handle thousands of requests/sec, for very long period of times (several hours) so it do not write all data to the disk (for performance reasons). Instead it computes on the fly an estimation of the mean and standard variation for each type of data, and writes these estimations every 10 seconds to the disk (and then starts a new estimation for the next 10 sec). These computations are done for two kinds of data: • sample, for things like response time • sample_counter when the input is a cumulative one (number of packet sent for ex.). There are also two other types of useful data (no averaging is done for those): • counter: a simple counter, for HTTP status code for ex. • sum for ex. the cumulative HTTP response’s size (it gives an estimated bandwidth usage). 7.4 Generating the report cd to the log directory of your test (say ~/.tsung/log/20040325-16:33/) and use the script tsung_stats.pl: /usr/lib/tsung/bin/tsung_stats.pl Note: You can generate the statistics even when the test is running! use –help to view all available options: Available options: [--help] (this help text) [--verbose] (print all messages) [--debug] (print receive without send messages) [--dygraph] use dygraphs (http://danvk.org/dygraphs/) to render graphs [--noplot] (don’t make graphics) [--gnuplot ] (path to the gnuplot binary) [--nohtml] (don’t create HTML reports) [--logy] (logarithmic scale for Y axis) [--tdir ] (Path to the HTML tsung templates) [--noextra (don’t generate graphics from extra data (os monitor, etc) [--rotate-xtics (rotate legend of x axes) [--stats ] (stats file to analyse, default=tsung.log) [--img_format ] (output format for images, default=png available format: ps, svg, png, pdf) Version 1.4.0 adds a new graphical output based on http://danvk.org/dygraphs/. 7.5 Tsung summary Figure Report shows an example of a summary report. 7.3. Design 57 Tsung Documentation, Release 1.5.1 Figure 7.1: Report 58 Chapter 7. Statistics and Reports Tsung Documentation, Release 1.5.1 7.6 Graphical overview Figure Graphical output shows an example of a graphical report. 7.7 Tsung Plotter Tsung-Plotter (tsplot} command) is an optional tool recently added in the Tsung distribution (it is written in Python), useful to compare different tests runned by Tsung. tsplot is able to plot data from several tsung.log files onto the same charts, for further comparisons and analyzes. You can easily customize the plots you want to generate by editing simple configuration files. You can get more information in the manual page of the tool (man tsplot). Example of use: tsplot "First test" firsttest/tsung.log "Second test" secondtest/tsung.log -d outputdir Here’s an example of the charts generated by tsplot (figure Graphical output of tsplot): 7.8 RRD A contributed perl script tsung-rrd.pl is able to create rrd files from the Tsung log files. It’s available in /usr/lib/tsung/bin/tsung-rrd.pl. 7.6. Graphical overview 59 Tsung Documentation, Release 1.5.1 Figure 7.2: Graphical output 60 Chapter 7. Statistics and Reports Tsung Documentation, Release 1.5.1 Figure 7.3: Graphical output of tsplot 7.8. RRD 61 Tsung Documentation, Release 1.5.1 62 Chapter 7. Statistics and Reports CHAPTER EIGHT REFERENCES • Tsung home page: http://tsung.erlang-projects.org/ • Tsung description (French) 1 • Erlang web site http://www.erlang.org/ • Erlang programmation, Mickaël Rémond, Editions Eyrolles, 2003 2 • Making reliable system in presence of software errors, Doctoral Thesis, Joe Armstrong, Stockholm, 2003 3 • Tutorial on How to write a Tsung plugin, written by t ty, http://www.process- one.net/en/wiki/Writing_a_Tsung_plugin/ 1 http://www.erlang-projects.org/Members/mremond/events/dossier_de_presentat/block_10766817551485/file 2 http://www.editions-eyrolles.com/php.accueil/Ouvrages/ouvrage.php3?ouv_ean13=9782212110791 3 http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf 63 Tsung Documentation, Release 1.5.1 64 Chapter 8. References CHAPTER NINE ACKNOWLEDGMENTS The first version of this document was based on a talk given by Mickael Rémond 1 during an Object Web benchmarking workshop in April 2004 (more info at http://jmob.objectweb.org/). 1 mickael.remond@erlang-fr.org 65 Tsung Documentation, Release 1.5.1 66 Chapter 9. Acknowledgments CHAPTER TEN FREQUENTLY ASKED QUESTIONS 10.1 Can’t start distributed clients: timeout error Most of the time, when a crash happened at startup without any traffic generated, the problem arise because the main Erlang controller node cannot create a “slave” Erlang virtual machine. The message looks like: Can’t start newbeam on host ’XXXXX (reason: timeout) ! Aborting! The problem is that the Erlang slave module cannot start a remote slave node. You can test this using this simple command on the controller node (remotehost is the name of the client node): >erl -rsh ssh -sname foo -setcookie mycookie Eshell V5.4.3 (abort with ^G) (foo@myhostname)1>slave:start(remotehost,bar,"-setcookie mycookie"). You should see this: {ok,bar@remotehost} If you got {error,timeout}, it can be caused by several problems: • ssh in not working (you must have a key without passphrase, or use an agent) • Tsung and Erlang are not installed on all clients nodes • Erlang version or location (install path) is not the same on all clients nodes • A firewall is dropping Erlang packets: Erlang virtual machines use several TCP ports (dynamically generated) to communicate (if you are using EC2, you may have to change the Security Group that is applied on the VMs used for Tsung: open port range 0 - 65535) • SELinux: You should disable SELinux on all clients. • Bad /etc/hosts: This one is wrong (real hostname should not refer to localhost/loopback): localhost myhostname This one is good: localhost myhostname • sshd configuration: For example, for SuSE 9.2 sshd is compiled with restricted set of paths (ie. when you shell into the account you get the users shell, when you execute a command via ssh you don’t) and this makes it impossible to start an Erlang node (if Erlang is installed in /usr/local for example). 67 Tsung Documentation, Release 1.5.1 Run: ssh myhostname erl If the Erlang shell doesn’t start then check what paths sshd was compiled with (in SuSE see /etc/ssh/sshd_config) and symlink from one of the approved paths to the Erlang executable (thanks to Gordon Guthrie for reporting this). • old beam processes (Erlang virtual machines) running on client nodes: kill all beam processes before starting Tsung. Note that you do not need to use the address in the configuration file. It will not work if you use it as the injection interface. The shortname of your client machine should not refer to this address. Warning Tsung launches a new Erlang virtual machine to do the actual injection even when you have only one machine in the injection cluster (unless use_controller_vm is set to true). This is because it needs to by-pass some limit with the number of open socket from a single process (1024 most of the time). The idea is to have several system processes (Erl beam) that can handle only a small part of the network connection from the given computer. When the maxusers limit (simultaneous) is reach, a new Erlang beam is launched and the newest connection can be handled by the new beam). New in 1.1.0: If you don’t use the distributed feature of Tsung and have trouble to start a remote beam on a local machine, you can set the use_controller_vm attribute to true: 10.2 Tsung crashes when I start it Does your Erlang system has SSL support enabled ? to test it: > erl Eshell V5.2 (abort with ^G) 1> ssl:start(). you should see ’ok’ 10.3 Why do i have error_connect_emfile errors? emfile error means : too many open files This happens usually when you set a high value for maxusers (in the section) (the default value is 800). The errors means that you are running out of file descriptors; you must check that maxusers is less than the maximum number of file descriptors per process in your system (see ulimit -n). You can either raise the limit of your operating system (see /etc/security/limits.conf for Linux) or de- crease maxusers Tsung will have to start several virtual machine on the same host to bypass the maxusers limit. It could be good if you want to test a large number of users to make some modifications to your system before launching Tsung: • Put the domain name into /etc/hosts if you don’t want the DNS overhead and you only want to test the target server • Increase the maximum number of open files and customize TCP settings in /etc/sysctl.conf. For exam- ple: 68 Chapter 10. Frequently Asked Questions Tsung Documentation, Release 1.5.1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.ip_local_port_range = 1024 65000 fs.file-max = 65000 10.4 Tsung still crashes/fails when I start it! First look at the log file ~/.tsung/log/XXX/tsung_controller@yourhostname to see if there is a prob- lem. If the file is not created and a crashed dump file is present, maybe you are using a binary installation of Tsung not compatible with the version of Erlang you used. If you see nothing wrong, you can compile Tsung with full debugging: recompile with make debug, and don’t forget to set the loglevel to debug in the XML file (see tsung.xml log levels). To start the debugger or see what happen, start Tsung with the debug argument instead of start. You will have an Erlang shell on the tsung_controller node. Use toolbar:start(). to launch the graphical tools provided by Erlang. 10.5 Can I dynamically follow redirect with HTTP? If your HTTP server sends 30X responses (redirect) with dynamic URLs, you can handle this situation using a dynamic variable: You can even handle the case where the server use several redirections successively using a repeat loop (this works only with version 1.3.0 and up): 10.6 What is the format of the stats file tsung.log? Sample tsung.log: 10.4. Tsung still crashes/fails when I start it! 69 Tsung Documentation, Release 1.5.1 # 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 ... the format is, for request, page, session and transactions tr_XXX: stats: name, 10sec_count, 10sec_mean, 10sec_stddev, max, min, mean, count or for HTTP returns codes, size_sent and size_rcv: stats: name, count(during the last 10sec), totalcount(since the beginning) 10.7 How can I compute percentile/quartiles/median for transactions or requests response time? It’s not directly possible. But since version 1.3.0, you can use a new experimental statistic backend: set backend="fullstats" in the section of your configuration file (also see File structure). This will print every statistics data in a raw format in a file named tsung-fullstats.log. Warning: this may impact the performance of the controller node (a lot of data has to be written to disk). The data looks like: {sum,connected,1} {sum,connected,-1} [{sample,request,214.635}, {sum,size_rcv,268}, {sample,page,831.189}, {count,200}, {sum,size_sent,182}, {sample,connect,184.787}, {sample,request,220.974}, {sum,size_rcv,785}, {count,200}, {sum,size_sent,164}, {sample,connect,185.482}] {sum,connected,1} 70 Chapter 10. Frequently Asked Questions Tsung Documentation, Release 1.5.1 [{count,200},{sum,size_sent,161},{sample,connect,180.812}] [{sum,size_rcv,524288},{sum,size_rcv,524288}] Since version 1.5.0, a script tsung_percentile.pl is provided to compute the percentiles from this file. 10.8 How can I specify the number of concurrent users? You can’t. But it’s on purpose: the load generated by Tsung is dependent on the arrival time between new clients. Indeed, once a client has finished his session in Tsung, it stops. So the number of concurrent users is a function of the arrival rate and the mean session duration. For example, if your web site has 1,000 visits/hour, the arrival rate is 1000/3600 = 0.2778 visits/second. If you want to simulate the same load, set the inter-arrival time is to 1/0.27778 = 3.6 sec (e.g. in the arrivalphase node in the XML config file). 10.9 SNMP monitoring doesn’t work?! It use SNMP v1 and the “public” community. It has been tested with http://net-snmp.sourceforge.net/. You can try with snmpwalk to see if your snmpd config is ok: >snmpwalk -v 1 -c public IP-OF-YOUR-SERVER . UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 1033436 SNMP doesn’t work with Erlang R10B and Tsung older than 1.2.0. There is a small bug in the snmp_mgr module in old Erlang release (R9C-0). This is fixed in Erlang R9C-1 and up, but you can apply this patch to make it work on earlier version: --- lib/snmp-3.4/src/snmp_mgr.erl.orig 2004-03-22 15:21:59.000000000 +0100 +++ lib/snmp-3.4/src/snmp_mgr.erl 2004-03-22 15:23:46.000000000 +0100 @@ -296,6 +296,10 @@ end; is_options_ok([{recbuf,Sz}|Opts]) when 0 < Sz, Sz =< 65535 -> is_options_ok(Opts); +is_options_ok([{receive_type, msg}|Opts]) -> + is_options_ok(Opts); +is_options_ok([{receive_type, pdu}|Opts]) -> + is_options_ok(Opts); is_options_ok([InvOpt|_]) -> {error,{invalid_option,InvOpt}}; is_options_ok([]) -> true. 10.10 How can i simulate a fix number of users? Use maxnumber to set the max number of concurrent users in a phase, and if you want Tsung to behave like ab, you can use a loop in a session (to send requests as fast as possible); you can also define a max duration in . 10.8. How can I specify the number of concurrent users? 71 Tsung Documentation, Release 1.5.1 72 Chapter 10. Frequently Asked Questions CHAPTER ELEVEN ERRORS LIST 11.1 error_closed Only for non persistent session (XMPP); the server unexpectedly closed the connection; the session is aborted. 11.2 error_inet_ Network error; see http://www.erlang.org/doc/man/inet.html for the list of all errors. 11.3 error_unknown_data Data received from the server during a thinktime (not for unparsed protocol like XMPP). The session is aborted. 11.4 error_unknown_msg Unknown message received (see the log files for more information). The session is aborted. 11.5 error_unknown Abnormal termination of a session, see log file for more information. 11.6 error_repeat_ Error in a repeat loop (undefined dynamic variable usually). 11.7 error_send_ Error while sending data to the server, see http://www.erlang.org/doc/man/inet.html for the list of all errors. 73 Tsung Documentation, Release 1.5.1 11.8 error_send Unexpected error while sending data to the server, see the logfiles for more information. 11.9 error_connect_ Error while establishing a connection to the server. See http://www.erlang.org/doc/man/inet.html for the list of all errors. 11.10 error_no_online XMPP: No online user available (usually for a chat message destinated to a online user) 11.11 error_no_offline XMPP: No offline user available (usually for a chat message destinated to a offline user) 11.12 error_no_free_userid For XMPP: all users Id are already used (userid_max is too low ?) 11.13 error_next_session A clients fails to gets its session parameter from the config_server; the controller may be overloaded ? 11.14 error_mysql_ Error reported by the mysql server (see http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html) 11.15 error_mysql_badpacket Bad packet received for mysql server while parsing data. 11.16 error_pgsql Error reported by the postgresql server. 74 Chapter 11. Errors list CHAPTER TWELVE CHANGELOG 1.5.0 -> 1.5.1 Major enhancements and bugfixes (7 Apr 2014) Bugfix: *[TSUN-250] - BOSH Crash *[TSUN-252] - Too many requests when using max_restart *[TSUN-253] - Code blocks in html version of user manual is unreadable *[TSUN-256] - Unexpected ack="global" behaviour on BOSH *[TSUN-265] - Wrong header line in tsung.dump *[TSUN-270] - Substitution not working in path attribute *[TSUN-271] - SSL does not work with erlang >= R16 *[TSUN-272] - Support literal IPv6 addresses when defining servers *[TSUN-278] - Tsung 1.5.0 is notable to do https out of the box when it is compiled from tarballs *[TSUN-279] - Tsung 1.5.0 is not able to do substitution of hostname or port in a URL. It only can do substitution of path *[TSUN-281] - Fix debian build for Tsung 1.5, replaces DocBook with Sphinx *[TSUN-285] - In some rare conditions in a distributed setup, Tsung fails to start the load test. *[TSUN-287] - request.max statistic lower than request.mean *[PR #71] - oAuth bug fix, PUT method *[PR #41] - Fix websocket path subst *[PR #44] - Add bidi attribute to change_type *[PR #49] - Fix websocket close issue: we should wait a close response Improvements: *[TSUN-255] - Fix unused vars in tq_amqp *[TSUN-259] - Tsung in Fedora *[TSUN-268] - Use xmerl_sax_parser:file/2 in case of xml parsing error *[TSUN-276] - Add text frame support for websocket *[TSUN-284] - Do not use boot files to start tsung and tsung_controller applications *[PR #51] - Updated dygraph charting library to the latest release *[PR #65] - AMQP: add multiple channel, add waitForConfirms and waitForMessages *[PR #70] - Add bosh_path config option *[PR #74] - Add text frame support for Websocket, and update doc New features: *[TSUN-260] - Add option to change popularities of sessions for each phase *[TSUN-264] - New comparison operators *[TSUN-269] - Logging of request tags to dumpfile *[TSUN-275] - Add MQTT support *[TSUN-280] - Tsung to support pkcs#12 certificates or at least cacerts, clientcerts and keys *[PR #42] - Adding all_except_body’ option to ts_http request subst. Adding mysqladmin monitoring options to erlang monitors. 75 Tsung Documentation, Release 1.5.1 Adding mean rate calculation to tsung_stats reports. Adding --title option to set header of report *[PR #75] - Support SSL/TLS client certificate file attributes for jabber starttls 1.4.2 -> 1.5.0 Major enhancements and bugfixes (24 May 2013) Bugfix: *[TSUN-208] - in the jabber plugin, substitutions for raw request doesn’t work in some cases. *[TSUN-209] - If tag doesn’t work with Tsung 1.4.2 *[TSUN-212] - Incorrect ERTS version being set on build. *[TSUN-215] - normal ack timeout shouldn’t used for global ack *[TSUN-217] - If statement breaks on empty string *[TSUN-218] - Race condition in tsung-recorder *[TSUN-219] - Site fails to load via proxy recorder *[TSUN-220] - Large configuration files trigger error *[TSUN-229] - compatibility with erlang R15B *[TSUN-230] - can’t connect with TLS + ejabberd *[TSUN-232] - Tsung for bosh protocol doesn’t send a empty request to keep the user session alive. *[TSUN-234] - Error encoding json string with escape_uri *[TSUN-238] - Content-Length parsing broken *[TSUN-241] - Invalid link Other in the graph.html *[TSUN-245] - Message when dtd is not found not trivial Improvements: *[TSUN-174] - add an option to set resource in XMPP *[TSUN-222] - Support unsubscribe operation for Jabber pubsub module *[TSUN-228] - allow substitutions on cookies *[TSUN-236] - Add probability support for servers *[TSUN-242] - add timestamp and request duration in dump=protocol for http *[TSUN-246] - http PATCH support New Features: *[TSUN-214] - Ability to pass attributes for node creation for XMPP pubsub protocol. *[TSUN-227] - add new dynamic variable to get server hostname and port *[TSUN-231] - add option to use weights instead of probabilities for sessions *[TSUN-239] - add BOSH support *[TSUN-240] - add websocket support *[TSUN-244] - Percentile computation *[TSUN-248] - add AMQP support 1.4.1 -> 1.4.2 Minor enhancements and bugfixes (4 Jan 2012) Bugfix: *[TSUN-199] - computation of NUsers is wrong *[TSUN-206] - build failure with erlang R15B Improvements: *[TSUN-202] - IPv6 support *[TSUN-203] - snmp oids should be customizable in the config file *[TSUN-205] - handle dyn_variables as array in test conditions (if/until/while) New Features: *[TSUN-191] - allow outputting log to stdout *[TSUN-192] - structured log output (JSON) *[TSUN-193] - accept configuration from stdin *[TSUN-197] - Have bug and error message on stderr and not stdout. 1.4.0 -> 1.4.1 Minor bugfixes (13 Sep 2011) Bugfix: *[TSUN-188] - munin plugin is not working in 1.4.0 *[TSUN-189] - the controller VM is not used in some case *[TSUN-190] - pgsql recorder can record a connect request in an already connected session 1.3.3 -> 1.4.0 Major enhancements and bugfixes (5 Sep 2011) Bugfix: *[TSUN-129] - regexp (defined in match or dynvars) can fail when chunk encoding is used. *[TSUN-150] - Munin monitoring broken by cpu stats config request 76 Chapter 12. Changelog Tsung Documentation, Release 1.5.1 *[TSUN-163] - Tsung doesn’t detect subdomains. *[TSUN-166] - snmp monitoring does not work with erlang R14A *[TSUN-171] - maxnumber set in a phase is not always enforced *[TSUN-172] - auth sasl can’t authenticate against ejabberd *[TSUN-178] - some characters can make url and headers rewriting fail in the recorder *[TSUN-179] - tsung generated message stanzas are not XMPP compliant *[TSUN-180] - file server crash if a dynamic substitution use it *[TSUN-182] - When many clients are configured with few static users, none of them are launched. *[TSUN-183] - tsung can stop too soon in some cases *[TSUN-184] - ’random_number’ with start and end actually returns a number from start+1 to end *[TSUN-187] - Client IP scan is very slow on Linux; also uses obsolete "ifconfig" Improvements: *[TSUN-54] - tsung is very slow when a lot of dynamic variables are set *[TSUN-96] - generating more than 64k connections from a single machine *[TSUN-106] - Add content-encoding support for dynvar extraction *[TSUN-123] - add option to read usernames from an external file for jabber *[TSUN-125] - use the new re module everywhere instead of regexp/gregexp *[TSUN-152] - Add "state_rcv" record as parameter to "get_message" function. *[TSUN-153] - dynvar used in match may contain regexp special characters *[TSUN-185] - handle postgresql extended protocol New Features: *[TSUN-162] - add foreach tag (loop when a dyn_variable is a list) *[TSUN-164] - add a switch to allow light queries/replies logging *[TSUN-165] - add a way to synchronize users for all plugins. *[TSUN-167] - add do=dump option to matching *[TSUN-168] - thinktimes value could be dynamically generated with dyn_variable *[TSUN-181] - add option to simulate slow connections 1.3.2 -> 1.3.3 Minor bugfixes (17 Aug 2010) Bugfix: *[TSUN-154] - parent proxy doesn’t work anymore in 1.3.x (tested with 1.3.2 and 1.3.0). *[TSUN-155] - url substitution is broken in some cases *[TSUN-156] - Tsung not using sessions with low probabilities *[TSUN-157] - ssl doesn’t work with erlang R14A *[TSUN-158] - failure when a proxy is used and an URL substitution is set *[TSUN-159] - HTTP cookies support is broken when a proxy is used *[TSUN-160] - tsung can sometimes hang at the beginning using distributed setup *[TSUN-161] - if statement not allowed in a transaction 1.3.1 -> 1.3.2 Major bugfixes and enhancements (14 Jun 2010) Bugfix: *[TSUN-128] - Apostrophes cause string to convert to deep list in setdynvars with Erlang function. *[TSUN-130] - static users starting time is wrong *[TSUN-131] - tsung can stop too early when static users are used *[TSUN-132] - http cookies: accept domains equals to hostname with a leading "." *[TSUN-133] - proxy-recorder with SSL fails on large client packets (multiple TCP packets) *[TSUN-138] - when an error occured( for ex a timeout during a request) and a client exits, started transactions are not updated *[TSUN-140] - tsung does not honor the Proxy-Connection: keep-Alive or Connection: keep-Alive header if the proxy is HTTP/1.0 *[TSUN-142] - http recorder can fail with https rewriting and chunked encoding *[TSUN-147] - UDP & bidi does not seem to work *[TSUN-148] - dynvar not found when used in match *[TSUN-149] - tsung doesn’t work with Amazon Elastic load balancing *[TSUN-151] - tsung_stats.pl produces invalid *.gplot files Improvements: *[TSUN-82] - XMPP vhost support *[TSUN-127] - add ability tu use floats for thinktimes *[TSUN-139] - option to set random seed for launchers. *[TSUN-141] - add dynamic variable support for postgres *[TSUN-146] - New tsplot yfactor configuration support breaks most common configurations New Features: 77 Tsung Documentation, Release 1.5.1 *[TSUN-135] - add support for SASL ANONYMOUS and PLAIN authentication for XMPP *[TSUN-136] - add new plugin distributed testing of filesystem (nfs for ex), using a generic mode for executing erlang functions on clients nodes *[TSUN-137] - add a way to mix requests types inside a single session *[TSUN-143] - global time limit for the load test *[TSUN-145] - tsung should support json parsing for dynamic variable 1.3.0 -> 1.3.1 Major bugfixes and enhancements (9 Sep 2009) Bugfix: *[TSUN-92] - the computation of the minimum for sample_counter is wrong *[TSUN-93] - maxnumber not respected if several clients are used *[TSUN-102] - dyn_variable configuration fails if variable name is not a valid erlang atom *[TSUN-103] - Network error handling in munin plugin *[TSUN-104] - tsung-plotter can’t handle the os_mon statistics *[TSUN-108] - Cannot handle complicated dyn_var name *[TSUN-109] - Tsung status displays always phase one even if you have more than one phase *[TSUN-110] - Cookie header not present if the URL is dynamically generated by a previous redirection (302) *[TSUN-117] - Bug in HTTP: empty header can be generated in some case *[TSUN-118] - HTTPS proxy recorder: ts_utils:to_https incorrectly handles Content-Length for POST requests *[TSUN-119] - tsung can crash when reading empty values from a csv file *[TSUN-122] - same http cookie key with different domains don’t work Improvements: *[TSUN-47] - ts_mon can be a bottleneck during very high load testing *[TSUN-77] - Structural requests or goto-like action for match in HTTP *[TSUN-81] - Dynamic variables API *[TSUN-83] - file_server using fixed tuple instead of list *[TSUN-85] - external entity should be copied into the log directory of a run. *[TSUN-87] - add dynamic code evaluation in set_dynvars *[TSUN-88] - add mkactivity method support in webdav *[TSUN-91] - reduce memory consumption by hibernating client process while in think state *[TSUN-97] - disable smp erlang for client beam for performance reason *[TSUN-98] - try several times to connect to the server before aborting a session *[TSUN-99] - make substitution work in *[TSUN-100] - improve scalability of ts_launcher *[TSUN-105] - Add load average statistic to server monitoring *[TSUN-111] - add option to manually add a cookie in http requests *[TSUN-113] - split tsung command into two separate tsung and tsung-recorder commands *[TSUN-116] - add ability to run several tsung running in parallel on the same hosts *[TSUN-120] - Https recorder: Remove "Secure" from "Set-Cookie" header. New Features: *[TSUN-25] - add a way to start sessions in a specific order at specified times *[TSUN-89] - include tsung-plotter into the tsung distribution *[TSUN-90] - add support for monitoring server cpu/mem using munin-node *[TSUN-94] - add log action for match *[TSUN-95] - add a default dyn_variable with a unique tsung_userid *[TSUN-107] - add MUC support to the jabber doc/plugin *[TSUN-114] - add option to apply function to data before looking for a match *[TSUN-115] - add pubsub support to the jabber plugin 1.2.2 -> 1.3.0 Major bugfixes and enhancements (03 Sep 2008) Bugfix: *[TSUN-30] - SNMP monitoring gives an error *[TSUN-57] - using -l with a relative path make distributed load fails with timeout error *[TSUN-60] - https recorder broken if an HTML document includes absolute urls *[TSUN-67] - Typo breaks recording of if-modified-since headers *[TSUN-68] - some sites doesn’t work with ":443" added in the "Host" header with https *[TSUN-71] - Tsung does not work with R12B (httpd_util funs removed) *[TSUN-73] - Wrong parsing HTTP multipart/form-data in http request - POST form doesn’t work *[TSUN-75] - can not define more -pa arguments *[TSUN-84] - dyn variables that don’t match should be set to an empty string 78 Chapter 12. Changelog Tsung Documentation, Release 1.5.1 Improvements: *[TSUN-40] - problem to rewrite url for https with gzip-encoded html. *[TSUN-48] - tcp/udp buffer size should be customizable in the XML config file. *[TSUN-59] - if a User-Agent header is set in
, it should override the global one. *[TSUN-62] - add abilty to loop back to a previous request in a session *[TSUN-63] - check for ssl and crypto application at compile time *[TSUN-65] - enhance dynamic variables. *[TSUN-66] - add global mean and counter computation and reporting for samples *[TSUN-69] - add option to read content of a POST request from an external file *[TSUN-79] - setting ’Host’ header with http_header doesn’t work as expected New Features: *[TSUN-56] - ldap plugin *[TSUN-58] - add a new statistics backend to dump all stats in a file *[TSUN-61] - add a Webdav plugin *[TSUN-64] - add md5 authentication in the pgsql plugin *[TSUN-72] - Add support for defining dyn_variables using XPath *[TSUN-78] - mysql plugin *[TSUN-80] - add random thinktime with in a given range ( [min,max]) Tasks: *[TSUN-76] - add explanation for errors name in the documentation 1.2.1 -> 1.2.2 Minor bugfixes and enhancements (23 Feb 2008) Bugfix: *[TSUN-30] - SNMP monitoring gives an error *[TSUN-31] - dyn_variable usage *[TSUN-35] - udp is not working *[TSUN-36] - default regexp for dyn_variable doesn’t work in all case *[TSUN-38] - server monitoring crash if an ethernet interface’s name is more than 6 chars long *[TSUN-39] - https recording doesn’t work with most browsers *[TSUN-43] - session should not terminate if rosterjid is not defined *[TSUN-49] - doesn’t work with jabber plugin *[TSUN-51] - tsung does not work with R12B (httpd_util funs removed) *[TSUN-53] - postgresql errors not reported in all cases *[TSUN-55] - no error counter when userid_max is reached Improvements: *[TSUN-14] - no_ack messages and asynchronous msg sent by the server are not available in the reports *[TSUN-27] - handle bidirectional protocols *[TSUN-28] - Refactoring needed to ease the change of the userid / password generation code *[TSUN-29] - Multiple file_server support *[TSUN-32] - make snmp server options tunable *[TSUN-34] - add costum http headers *[TSUN-44] - tsung should ignore whitespace keepalive from xmpp server *[TSUN-45] - add kernel-poll support for better performance *[TSUN-46] - add number of open connections in statistics *[TSUN-47] - ts_mon can be a bottleneck during very high load testing *[TSUN-50] - use the whole range of Id (from 0 to userid_max) before reusing already used Ids New Features: *[TSUN-26] - Ability to loop on a given sequence of phase *[TSUN-52] - Adding comment during script capture *[TSUN-41] - add support for parent proxy for http only (not https) 1.2.0 -> 1.2.1 Minor bugfixes and enhancements (07 Oct 2006) Bugfix: - [TSUN-5] get traffic from all interfaces instead of only eth0 in erlang os monitoring (Linux) - [TSUN-18 the pgsql recorder fails if the client doesn’t try first an SSL connection - [TSUN-19] a % character in some requests (eg. type=sql for 79 Tsung Documentation, Release 1.5.1 pgsql) make the config_server crash. - [TSUN-20] pgsql client fails while parsing data from server - [TSUN-21] substitution in URL is not working properly when a new server or port is set - [TSUN-23] set default http version (1.1) - [TSUN-24] destination=previous doesn’t work (jabber) Improvement: - [TSUN-15] listen port is now customizable with the command line - [TSUN-17] add option to setup postgresql server IP and port at runtime for the recorder - [TSUN-22] add support for PUT, DELETE and HEAD methods for http 1.1.0 -> 1.2.0 Major feature enhancements (29 May 2006) - change name: idx-tsunami is now called tsung - add new plugin: pgsql for postgresql load testing - new: it’s now possible to set multiple servers (selected at runtime by round robin) - add size_rcv stats - fix beams communication problem introduced in new erlang releases. - import snmp_mgr src from R9C2 to enable SNMP with R10B - rebuild boot scripts if erlang version is different from compile time - many DTD improvements - improved match: add loop|abort|restart on (no)match behavior, multiple match tags is now possible (suggested by msmith@truelink.com) - freemem and packet stats for Solaris (jasonwtucker@gmail.com) - fix several small problems with ’use_controller_vm’ option - ip is no more mandatory (default is - clients and monitoring can use hosts list defined in environment variables, for use with batch schedulers (openpbs/torque, LSF and OAR) - performance improvements in stats engine for very high load (use session_cache) Recorder: - add plugin architecture in recorder; add pgsql plugin - fix regression in recorder for WWW-Authentication (anders.nygren@gmail.com) - close client socket when connection:closed is ask by the server (this should enable https recording with IE) Jabber: - fix presence:roster request - add presence:directed , presence:broadcast & presence:final requests for jabber (jasonwtucker@gmail.com) - roster enhancements (jasonwtucker@gmail.com) - sip-digest authentication (jasonwtucker@gmail.com) - fix online: must use presence:initial to switch to online status - add pubsub support (mickael.remond@process-one.net) Http: - fix single user agent case. - minor fixes for HTTP parsing 1.0.3 -> 1.1.0 Major feature enhancements (5 Sep 2005) - new feature: HTTP proxy load testing in now possible (set http_use_server_as_proxy to true) - add dynamic substitution support for jabber - add ’raw’ type of msg for Jabber (use the new ’data’ attribute) - add the dynamic variable list to dynamic substitutions - UserAgent is now customizable for HTTP testing - Add an option to run all components (controller and launcher) within a single erlang beam (use_controller_vm). Should ease 80 Chapter 12. Changelog Tsung Documentation, Release 1.5.1 idx-tsunami use for light load tests - fix bash script for solaris (jasonwtucker@gmail.com) - fix: several ’idx-tsunami status’ can be run simultaneously (reported by Adam Spotton) - internal: Host header is now set during configuration phase - fix last phase duration - fix recorder: must log absolute url if only the scheme has changed 1.0.2 -> 1.0.3 Minor bugfixes (8 Jul 2005) - add ts_file_server module - fix broken https recording Thx to johann.messner@jku.at for bug reporting : - fix: forgot to add "?" when an URL is absolute and had a query part - fix regression in the recorder (introduced in 1.0.2): must use CAPS for method, wrong content-length in recorder causing POST requests to silently fail - allow multiple ’dyn_variable’ in DTD - fix Host: header when port is != 80 1.0.1 -> 1.0.2: Minor bugfixes (6 Jun 2005) - fix: the recorder is working now with R10B: replace call to httpd_parse:request_header in recorder by an internal func (the func was removed in R10B) - update configure scripts (should build on RHEL3/x86_64) - remote beam startup is now tunable (-r ssh/rsh) - internal changes in ts_os_mon (suggested by R. Lenglet) 1.0 -> 1.0.1: Major bugfixes (18 Nov 2004) - fix: broken free mem on non linux arch (Matthew Schulkind) - add script to convert apache log file (combined) to idx-tsunami XML - improved configure: add --with-erlang option and xmerl PATH detection idx-tsunami now compiles both with R9C and R10B - small fixes to the DTD Thx to Jonathan Bresler for testing and bug reporting : - fix: broken ’global’, ’local’ and ’no_ack’ requests and size computation - fix: broken ids in jabber messages - fix: broken online/offline in user_server - default thinktime can now be overriden - many improvements/fixes in analyse_msg.pl 1.0.beta7 -> 1.0: Minor bugfixes (13 Aug 2004) - fix: broken path when building debian package - add rpm target in makefile - implement status - add ’match’ in graph and doc - fix add_dynparams for jabber 1.0.beta6 -> 1.0.beta7: Minor bugfixes (20 Jul 2004) - HTTP: really (?) fix parsing of no content-length with connection:close - better handling of configure (--prefix is working) - add different types of output backend (currently, only ’text’ works; ’rrdtool’ is started but unfinished) - fix: ssl_ciphers option is working again 1.0.beta5 -> 1.0.beta6: Minor feature enhancements (5 May 2004) - add a DTD for the configuration file - add dynamic request substitution (mickael.remond@erlang-fr) 81 Tsung Documentation, Release 1.5.1 - add dynamic variable parsing from response (can be used later in the session for request substitution) - add response pattern to match (log if not match) - HTTP: fix partial header parsing (mickael.remond@erlang-fr.org) - HTTP: fix chunk parsing when the chunk-size is split across two packets - HTTP: fix parsing of no content-length with connection:close case - check for bad input (config file, name) - merge client and client_rcv processes into a single process - fix: do not connect in init anymore; this fix too long phases when connection time is high. - connect stat is now for both new connections and reconnections - check phase duration in launcher - various code cleanup 1.0.beta4 -> 1.0.beta5: Major Feature enhancements (25 Mar 2004) - add SNMP monitoring (not yet customizable) - fix remote start: log filename is now encoded to avoid bad parsing of log_file by ’erl’ Patches from mickael.remond@erlang-fr.org : - Added ~/.idx-tsunami creation in idx-tsunami script if the directory does not already exist - Extension of XML attribute entity normalisation - HTTP: fix Cookie support: Cookie are not necessarily separated by "; " - HTTP: fix long POST request in the recorder: dorecord message was missing enclosing curly brackets, and the body length counter were mistakenly taking the header size in its total - HTTP: Content-type support in the recorder (needed to handle non-HTML form encoded posts) - add autoconf support to detect Erlang installation path - SOAP Support: IDX-Tsunami can now record and replay SOAP HTTP scenario. The SOAPAction HTTP header is now recorded - Preliminary Windows support: A workaround has been introduced in the code to handle behaviour difference between Erlang Un*x and Erlang Windows on how the command-line is handled. When an assumtion is made on the string type of a parameter, it should be check that this is actually a string and not an atom. 1.0.beta3 -> 1.0.beta4: Minor bugfixes (16 Mar 2004) - fix lost cookie when transfer-encoding:chunked is used - fix config parsing (the last request of the last page of a sesssion was not marked as endpage) - don’t crash anymore on error during start or stop 1.0.beta2 -> 1.0.beta3: Minor feature enhancements (24 Feb 2004) - fix stupid bug in start script for recorder - HTTP: fix ’&’ writes in the XML recorder for ’content’ attribute - HTTP: enhanced Cookies parsing (’domain’ and ’path’ implemented). - ssl_ciphers can be customized - change log directory structure: all log files in one directory per test - add HTML reports (requires the perl Template toolkit) - change stats names: page_resptime -> page, response_time -> request 1.0.beta1 -> 1.0.beta2: Minor feature enhancements (11 Feb 2004) - reorganise the sources - add tools to build a debian package - fix documentations - add minimalistic man page - syntax change: GETIMS +date replace by GET +’if_modified_since’ 82 Chapter 12. Changelog Tsung Documentation, Release 1.5.1 0.2.1 -> 1.0.beta1: Major Feature Enhancements (3 Feb 2004) - rewrite the configuration engine. Now use an XML file. - add recording application: use as a HTTP proxy to record session into XML format - add support to OS monitoring (cpu, memory, network). Currently, use an erlang agent on the remote nodes; SNMP is on the TODO list. (mickael.remond@erlang-fr.org) - can now use several IPs per client host - several arrival phases can be set with different arrival rates and duration - can set test duration instead of number of users - add user defined statistics using a ’transaction’ tag - HTTP: fix cookies and POST handling (mickael.remond@erlang-fr.org) - HTTP: rewrite the parser (faster and cleaner) - fix bad timeout computation when close occur for persistent client - bugfixes and other enhancements. - fix memory leak with ssl (half-closed connections) 0.2.0 -> 0.2.1: Minor bugfixes and small enhancements (9 Dec 2003) - optimize session memory consumption: use an ets table to store session setup - HTTP: fix crash when content-length is not set in headers - HTTP: fix POST method - HTTP: preliminary chunked-encoding support in HTTP/1.1 - HTTP: Absolute URL are handled (server and port can be overridden ) - no more .hosts.erlang required - add stats on simultaneous users 0.1.1 -> 0.2.0: Major Feature Enhancements (Aug 2003) - add ’realtime’ stats - add new ’parse’ type of protocol - add reconnection support (persistent client) - add basic HTTP and HTTPS support - split the application in two parts: a single controller (tsunami_controller), and the clients (tsunami) - switch to R9C 0.1.0 -> 0.1.1: Bugfix realease (Aug 2002) - fix config file - fix few typos in docs - fix init script - few optimizations in user_server.erl - switch to R8B 0.1.0: Initial release (May 2001) 83 Tsung Documentation, Release 1.5.1 84 Chapter 12. Changelog CHAPTER THIRTEEN TSUNG-1.0.DTD 85 Tsung Documentation, Release 1.5.1 86 Chapter 13. tsung-1.0.dtd Tsung Documentation, Release 1.5.1 93 Tsung Documentation, Release 1.5.1 94 Chapter 13. tsung-1.0.dtd CHAPTER FOURTEEN INDICES AND TABLES • genindex • search 95 Tsung Documentation, Release 1.5.1 96 Chapter 14. Indices and tables INDEX A apply_to_content, 50 arrivalphase, 21 arrivalrate, 21 B batch, 19 C callback, 48 change_type, 43 client, 18 cpu, 18 D delimiter, 48 dtd, 83 dumptraffic, 17 duration, 22 dyn_variable, 46 E emfile, 68 encoding, 17 F faq, 65 fileid, 48 for, 50 foreach, 51 G global_ack_timeout, 23 global_number, 12 H hibernate, 23 host, 18 http_use_server_as_proxy, 11 I idle_timeout, 23 if, 51 interarrival, 13, 21 ip, 19 iter, 48 J jabber, 28 json, 55 jsonpath, 47 L load, 21 loglevel, 17 M match, 49 maxnumber, 13, 21 maxusers, 19 munin, 21 O options, 23 override, 23 P page, 56 presence, 12 proxy, 14 R rate_limit, 23 record_tag, 15 redirect, 69 repeat, 51 RFC RFC 3253,6 RFC 3921, 31 RFC 4918,6 RFC 6455,7 97 Tsung Documentation, Release 1.5.1 S sample, 57 sample_counter, 57 sasl plain, 30 scan_intf, 19 scheduler, 19 seed, 24 server, 18 session, 25 setdynvars, 48 skip_headers, 50 snmp, 20 ssl_ciphers, 23 start_time, 22 T tag, 52 tcp_rcv_buffer, 23 tcp_snd_buffer, 23 thinktime, 23 thinktimes, 26 ts_http, 11 ts_jabber, 12 ts_user_server, 44 tsung-recorder, 14 U udp_rcv_buffer, 23 udp_snd_buffer, 23 until, 51 use_controller_vm, 18 W weight, 18 while, 51 X xpath, 46 98 Index



需要 6 金币 [ 分享文档获得金币 ] 1 人已下载