Re: improving concurrent transactin commit rate

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: improving concurrent transactin commit rate
Date: 2009-03-28 21:34:24
Message-ID: 7EBD9D20-A13F-461E-AA00-DDADE279E08E@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Le 27 mars 09 à 21:42, Sam Mason a écrit :
> OK, that's turned out to be a good point. I've now written five
> different versions and they don't seem to give the results I'm
> expecting
> at all!

If you're that much willing to have a good concurrent load simulator
client for postgresql, my take is for you to test tsung. This surely
will take less time than rewriting it with result I'd suspect less
efficient than the 20+ years of research that came into Erlang design
and implementation :)
http://tsung.erlang-projects.org/
http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php

Your task will be to install erlang and tsung, then to write up a load
parameter XML script embedding your SQL requests as CDATA. You could
define more than one session and ask to mix what session each
simulated user will run (70% of this, 20% of that, 10% of the latter),
and give a thinktime between some requests, will get be respected on
average (with a grain of randomness).

Have fun,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-03-28 22:05:30 Re: 8.4 release notes proof reading 1/2
Previous Message Merlin Moncure 2009-03-28 20:52:02 Re: PQinitSSL broken in some use casesf