Running Tsung against opentaps server

From Opentaps Wiki

Jump to: navigation, search

This is a page to assist with running tsung against opentaps server.

Contents


Installing tsung

Tsung needs the erlang platform to be installed. We will not extend over it, because rpm or deb versions just runs fine. http://www.erlang.org/

Tsung is a tool only available for linux platform under binary form. Maybe it could be runned against windows with the erlang windows version and the cygwin platform.

We used Tsung with erlang 5.6.1 or 13.2.2. The version 1.2.2 has some problem linked to xml parsing, newer version like 1.3.1 should work as well. In the rest of this document we will assume the version 1.2.0.

You may want to modify tsung-1.2.0/src/tsung_controller/ts_os_mon.erl, depending on which platform you are running the opentaps server. The scripts which do the os monitoring (cpu, memory and network graphs) may not be convenient for your platform.

Compilation

  • For debian users, just type fakeroot debian/rules binary.
  • For the others a ./configure, make, make install will do it.

Quick start

$ cd hot-deploy/opentaps-tests/scripts/tsung/
$ erlc readcsv.erl 
$ tsung -f tsung.xml start

then goto the log directory (default ~/.tsung/logs/YYYYMMDD-HH:SS).

$ /usr/lib/tsung/bin/tsung_stats.pl

open report.html in a web browser.

Configuration file

The configuration file and all the file needed to do a tsung stress testing are available in the directory hot-deploy/opentaps-tests/scripts/tsung/

  • readcsv.erl a small erlang script used to generate the login string from the user and password read
  • tsung.xml the configuration file for tsung
  • userlist.csv the list of the users which will be used successively to login

readcsv.erl

In this file, there is only one function called user. The step done are:

  • ts_file_server:get_next_line() to read one line in the file
  • string:tokens(Line,";") to separate the user and the password
  • "USERNAME=" ++ Username ++"&PASSWORD=" ++ Passwd to return the login string

You have to compile this file

$ erlc readcsv.erl 

You will get a file called readcsv.beam, which you have to copy in the tsung binary directory (note: no longer necessary when running tsung from the same directory in newer versions). In our case it is

/usr/lib/erlang/lib/tsung-1.2.0/ebin/

tsung.xml

The tsung.xml file is the configuration file which has the different scenarios to execute. There is some comments in there.

Here is an overview:

Configuration of the client

By default only one http client is configured which is localhost. You can configure as many http clients as you want. The computer which fires the tests must have a ssh access with passphrase.

  <clients>
    <client host="localhost" use_controller_vm="true"/>
  </clients>

Configuration of the server

By default the opentaps http server is configured on localhost:8443. You can change it too.

  <servers>
    <server host="localhost" port="8443" type="ssl"/>
  </servers>

Configuration of the monitoring (cpu, memory, network)

The monitoring has to be configured to access the opentaps server. In our case it is localhost. The computer which fires the tests must have a ssh access with passphrase.

  <monitoring>
    <monitor host="localhost" type="erlang"/>
  </monitoring>

Arrival of the clients on the tested server

It is configured in the load node and by a phase system. For each phase you put the duration of the phase and the frequency of arrival of the clients. You can have as many phase as you want. In this case, there is one phase of one minute which is configured, where clients arrived each 25 seconds. We will have 4 clients.

  <load>
   <arrivalphase phase="1" duration="1" unit="minute">
     <users interarrival="25" unit="second"/>
   </arrivalphase>
  </load>

The different options

  • user_agent UserAgent string to use
  • thinktime The thinktime of a user between his last response received and the next request he will send.
  • file_server the file with the login
  <options>
    <!-- which type of client are we going to fire -->
   <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>
    <!-- Each client has a random thinktime (time between two request) around 3 -->
   <option name="thinktime" value="3" random="true" override="true"/>
    <!-- TOBEMODIFIED Absolute path for the file from which we generate the login and password -->
   <option name="file_server" value="userlist.csv"/>
  </options>

userlist.csv

It is a basic csv file which associate on one line a user and a password separated by a ; ie

DemoSalesManager;crmsfa

This users will be used successively to login into the opentaps server.

Logs, Reports and Graphics generated

Logs

In the directory ~/.tsung/log/ you will get the logs file.

  • tsung_controller@FabsLaptop.log is the log where you can have the errors related to tsung
  • tsung.dump is the dump of all the requests and responses generated
  • tsung.log is used to generate the reports and graphics
  • tsung.xml is the configuration file

To generate the reports and graphics, just execute /usr/lib/tsung/bin/tsung_stats.pl in the directory of logs.

You can then open the generated report.html in a web browser.

Reports

  • Main statistics

Image:mainStatistic.png

connect is the time to make a tcp connect page is the time to download a whole page request is the time to send a request session is the time to get through a scenario node in the configuration file (in our case, to create and approve an order)

  • Transactions Statistics

Image:transactionsStatistic.png

tr_approveSalesOrder is the time to get through the transaction node in the configuration file called approveSalesOrder tr_createSalesOrder is the time to get through the transaction node in the configuration file called createSalesOrder tr_login is the time to get through the transaction node in the configuration file called login

  • Network Throughput

Image:networkThroughput.png

size_rcv is the quantity of bits received size_sent is the quantity of bits sent

  • Counters Statistics

Image:countersStatistics.png

finish_users_count match is the quantity of verification done by the match node, which success newphase nomatch is the quantity of verification done by the match node, which fails users_count is the quantity of users generated

  • Server monitoring

Image:serverMonitoring.png

cpu is the consumption of cpu freemem is the free memory available recvpackets is the quantity of bits received sentpackets is the quantity of bits sent

  • HTTP return code

Image:httpReturnCode.png

The apparition of the different http code. We observe 200, which is the normal http back code, and 302, which is received sometimes. This is normal I observe both during the building of the scenario.

Graphics

  • Response Time

Image:graphes-Transactions-mean.png

Mean

page correspond to the mean time to charge one page tr_* correspond to the mean time to charge one page in the specified transaction

Image:graphes-Perfs-mean.png

Mean

connect correpond to the mean time to do a tcp connect request correspond to the mean time to do a http request

  • Throughput

Image:graphes-Transactions-rate.png

Rate

page correspond to the mean time to charge one page tr_* correspond to the mean time to charge one page in the specified transaction

Image:graphes-Perfs-rate.png

Rate

connect correpond to the mean time to do a tcp connect request correspond to the mean time to do a http request

Image:graphes-Size-rate.png

Quantity of bit sent and received

Image:graphes-Users_Arrival-rate.png

Quantity of users doing an operation at the same time

  • Simultaneous Users

Image:graphes-Users-simultaneous.png

simultaneous users

Image:graphes-Match-rate.png

Matching response or not

  • Server OS monitoring

Image:graphes-cpu-mean.png

cpu mean

Image:graphes-freemem-mean.png

freemem mean

  • HTTP return code Status (rate)

Image:graphes-HTTP_CODE-rate.png

different http code returned

Troubleshooting

When writing custom tsung transaction (series of requests), make sure to use POST for request that are for ofbiz services, else you will have a security error message in the log.

In order to test more than 100 concurrent transactions with, your would first need to increase the number of threads in the connectors configuration in framework/base/config/ofbiz-containers.xml (see http-connector, https-connector, ajp-connector). Else you will see the actual number of connected users capped to the max thread value in the tsung report.



© Open Source Strategies, Inc. Development of this documentation site is sponsored by Open Source Strategies, Inc.
Help support opentaps with a subscription to this documentation site.