Re: Best way to load test a postgresql server

I considered Tsung myself but haven't tried it. If you intend to, I suggest
you read this excellent tutorial on using Tsung for test-loading
Postgresql<http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php>.
While impressed I decided the procedure was too daunting and went with
JMeter :-) It too can run test from multiple clients and has built in tables
and graphs and you can save results as CSV or XML etc. In particular I
recommend adding the extenion "listener" (JMeter term for anything that
captures and portrays test results) called Statitical Aggregate Report.

May the force be with you,

-- Shaul

On Wed, Jun 3, 2009 at 12:29 PM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>wrote:

> "Kenneth Cox" <kenstir(at)gmail(dot)com> writes:
> > On Tue, 02 Jun 2009 05:26:41 -0400, Dimitri Fontaine
> > <dfontaine(at)hi-media(dot)com> wrote:
> >> I'd recommand having a look at tsung which will be able to replay a
> >> typical application scenario with as many concurrent users as you want
> >> to: http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php
> >> http://tsung.erlang-projects.org/
> >> http://pgfouine.projects.postgresql.org/tsung.html
> >
> > I am having a look at tsung and not getting very far yet. Have you had
> luck
> > with it and do you really mean as many concurrent users as you want?
>
> Last time I used it it was in the context of a web application and to
> compare PostgreSQL against Informix after a migration. So I used the
> HTTP protocol support of the injector.
>
> Tsung is based on erlang and can be run from more than one node at any
> time, last time I checked you could run 600 to 800 concurrent clients
> from each node. Recent versions of erlang allow a much greater number
> per node, one or two orders of magnitude greater, as I've been told by
> Tsung's main developer.
>
> > I was
> > hoping to use it to simulate my current load while tuning and making
> > improvements. So far tsung doesn't appear well suited to my needs. I
> use
> > persistent connections; each tsung session uses a new connection. I have
> > multiple applications that have very usage patterns (some web and largely
> > idle, some non web and almost saturated); tsung has virtual users
> choosing
> > a session based on a probability with think times. I know many
> programming
> > languages; tsung (and its error messages) is in erlang.
>
> Tsung can be setup as an http or postgresql proxy: in this mode it'll
> prepare session files for you while you use your application as
> usual. The thinktime it sees will then get randomized at run time to
> better reflect real usage.
>
> You can define several user arrival phases to see what happens when the
> load raises then get back to normal traffic. Lots of options, really.
>
> Tsung generates statistics and comes with tools to analyze them and
> provide graphs organized into a web page, one of those tools allow to
> draw graphs from different simulations onto the same chart, with the
> same scaling, in order to easily compare results.
>
> It seems to me tsung is a good tool for your use case.
>
> Regards,
> --
> dim
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>