Re: Best way to load test a postgresql server - Mailing list pgsql-performance

From Dimitri Fontaine
Subject Re: Best way to load test a postgresql server
Date
Msg-id 87iqjdy8bl.fsf@enterprise.technique.hi-media-techno.com
Whole thread Raw
In response to Re: Best way to load test a postgresql server  ("Kenneth Cox" <kenstir@gmail.com>)
Responses Re: Best way to load test a postgresql server
Re: Best way to load test a postgresql server
List pgsql-performance
"Kenneth Cox" <kenstir@gmail.com> writes:
> On Tue, 02 Jun 2009 05:26:41 -0400, Dimitri Fontaine
> <dfontaine@hi-media.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

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unexpected query plan results
Next
From: James Mansion
Date:
Subject: Re: Scalability in postgres