[Tsung] Performance of ephemeral sessions
nicolas at niclux.org
Thu Nov 21 00:11:09 CET 2013
Edward Garson ecrivait le 20/11/2013 21:00:
> Hello Tsung-Users,
> I have seen some results in a particular usage of Tsung that I would like
> some clarification about.
> I want to generate load on a simple RESTful service that will experience
> many short-lived sessions. The service is merely GET with a simple query
> parameter and returns a small JSON payload to mobile devices. I figured
> Tsung should prove invaluable to test this service, particularly as it has
> to contend with many concurrent connections.
> To model this correctly, I thought that I should not loop in my <request>
> because that would constitute multiple requests from a single client (i.e.
> a longer-lived session) as opposed to very many short-lived sessions. So my
> single <session> contains a single <request> of type <http>. (Is my
> understanding correct here?)
> However, no matter what arrival phases I define and irrespective of their
> particular durations, I am unable to generate a load in excess of ~1000tps.
> This seemed inordinately low, so a colleague hacked up a "poor man's tsung"
> in Java using ThreadPoolExecutor and a runnable that opens a single socket,
> stuffs an HTTP GET down it and closes the socket again. That hackish code
> achieves 13,000tps with virtually no optimizations. The client/test box is
> a 16-core machine running SMP-enabled Erlang and i specify 10 cpus in the
> <client> section (use_controller_vm="false").
> I am troubled by this result and figure there is a simple explanation
> (probably: I'm making a dumb mistake :-). Surely tsung should be able to
> "outperform" ThreadPoolExecutor. I have been very successful with tsung in
> the past testing more involved services.
> Thanks for any insight you can provide
Can you show your complete xml file ? i would like to reproduce your load
using the same parameters.
Starting a new session in Tsung is much more heavy weight than sending a
new request .
Using an 5 years old 8 cores machine, you can do more than 60000 req/sec
(with a few sessions sending requests in a <for> loop); but you won't be
able to do more than a few thousands sessions per sec. (1000 seems quite
You could try to use less sessions, but with several requests inside.
Currently, nothing exists to "reset" a session, but you can simulate this
by using a fake "change_type" with store = false (this will force a close
connection and delete cookies and so on)
something like this:
<change_type new_type="ts_http" host="foo.bar" port="80" server_type="tcp"
the sessions should looks like this:
Maybe we need a better way to handle this specific use case ...
More information about the Tsung-users