[Tsung] postgresql testing - authentication / phases / open connections

[Michael Nacos]

Hello to everyone.

<some background>

I am a total Erlang newbie (I-have-written-a-little-bit-of-demo-code level)
but I am falling in love with the language.
I have also just started a new job, as Postgresql DBA and Tsung may just be
my big Erlang break:
My company has serious load testing needs, Tsung is exactly what they
couldn't find before, it's got a postgres module,
and a big part of my job will be scalability tests, so Tsung might just be
my ticket to programming Erlang professionally
(they will probably be very happy if I come up with some Erlang code for
test case randomization or other cool things)
And, by the way, I really enjoyed the Erlang Exchange. Thanks, guys.

</some background>

I have been trying to load test one of our development Postgres servers,
using a very simple setup (no distribution/
coordination of multiple machines). Now, the results I get if I run my test
scenario on the actual db server present
some qualitative differences compared to the results I get if the tests
originate on another machine connecting through
port 5432 (-- I am using the same tsung.xml file in both cases, of course)

The total size_sent (kbits) lines in both cases match the relevant patterns
in the users arrival graph. The size_rcv lines
are not consistent, though. In the local test, the size_rcv line linearly
grows up to 100 users (simultaneous) then becomes
horizontal - which may have something to do with the default postgres
setting for 100 max_connections. Does this mean
the same original 100 connections are maintained throughout the test, even
after the queries have finished, so there is no
more data coming in?

The size_rcv line for the remote test, however, always stays very near zero.
Now, the total errors graph matches exactly the
total user arrival graph, so I am kind of assuming something is going
horribly wrong with the remote queries (users
send by don't receive).

Now, I have tried to run the following line in both machines (local and
remote, where local is the server) and it works
fine in both cases. The only difference is I am using the trust model for
local pg connections (so I don't get asked for
a password when I run this on the server) and the md5 model for remote pg
connections (so I get asked for a password
when I run this on the remote machine) - I am assuming this is an
authentication problem, then.

cat test.sql | psql -U user -h localhost -p 5432 database

I have also tried to change the model for remote pg connections to password
(clear text over the net, bad idea), but I
get exactly the same behaviour. Is there something broken with tsung's
authentication mechanism, or is there something
wrong in my xml file:

    <transaction name="connection">
        <request>
           <pgsql type="connect" database="database" username="user" />
        </request>
    </transaction>

    <request><pgsql type="authenticate" password="pass"/></request>

Another thing concerns arrival phases:

I have specified three arrival phases in the xml file, a fast one followed
by a slow one, followed by a fast one (this
doesn't need to make sense, I am just experimenting with the software).
Tests from the local machine show an
expected ladder-like pattern when it comes to the
graphes-Users_Arrival-total graph, tests from the remote machine
don't (it's quite linear). Similar patterns may be observed in the total
kbits size_sent graphs and the total errors graphs,
so I think for some reason user arrival doesn't go as planned in the remote
test box case. Any ideas?

There is also the matter of finished users in the local test. For some
reason, those 100 users which are able to
connect don't seem to finish. In fact, there is a constant difference of
about 100 users between users_count and
finish_users_count throughout the graph, start to finish.
The number of simultaneous connections which remain after the end of the
experiment confirms this.
Should this happen, considering I have included the following line in
tsung.xml?

    <request><pgsql type="close"></pgsql></request>

Finally, in the transaction graphs I also get something called page (which,
by the way, is huge - its mean value
reaches 60000 msec at some stages).

Any help will be appreciated...

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.process-one.net/pipermail/tsung-users/attachments/20080704/fe28827e/attachment.html