From: | Ben Chobot <bench(at)silentmedia(dot)com> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Greg Stark" <gsstark(at)mit(dot)edu>, "pgsql-general" <pgsql-general(at)postgresql(dot)org> |
Subject: | [SPAM] Re: pgreplay log file replayer released |
Date: | 2010-03-23 16:25:49 |
Message-ID: | 99DA0623-AB2E-4115-800B-0AFD556D1C56@silentmedia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-announce pgsql-general |
On Mar 23, 2010, at 4:08 AM, Dimitri Fontaine wrote:
>> One thing that Tsung, recording
>> queries as proxy, will never be able to handle are encrypted connections,
>> but I guess that's a minor problem.
>
> Yes, because you typically run the proxy only to record sessions, in
> order to prepare the tsung setup. Another way to go from logs is to use
> pgfouine, which knows how to prepare a tsung config from PostgreSQL
> logs:
>
> http://pgfouine.projects.postgresql.org/tsung.html
We've actually found that pgfouine, while a great tool for most things, does not do a terribly good job at recreating production sessions for tsung. This isn't pgfouine's fault (although there is a bug there I still need to file) but rather with the fundamental design of Tsung and its origins as a tool to test stateless servers. If I want to replay a log *exactly* as it happened, tsung cannot help me.
I definitely look forward to using pgreplay the next time we need to compare hardware classes on known production load.
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-03-28 18:55:00 | == PostgreSQL Weekly News - March 28 2010 == |
Previous Message | Albe Laurenz | 2010-03-23 13:20:49 | Re: pgreplay log file replayer released |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-23 16:41:42 | Re: Fwd: Before triggers and usage in partitioned tables |
Previous Message | Tom Lane | 2010-03-23 15:49:00 | Re: strange |