From: "Claudio Freire" <klaussfreire@xxxxxxxxx>
On Wed, May 9, 2012 at 7:34 PM, MauMau <maumau307@xxxxxxxxx> wrote:
Yes, I understand it is natural for the response time of each transaction
to
double or more. But I think the throughput drop would be amortized among
multiple simultaneous transactions. So, 50% throughput decrease seems
unreasonable.
I'm pretty sure it depends a lot on the workload. Knowing the
methodology used that arrived to those figures is critical. Was the
thoughput decrease measured against no replication, or asynchronous
replication? How many clients were used? What was the workload like?
Was it CPU bound? I/O bound? Read-mostly?
We have asynchronous replication in production and thoughput has not
changed relative to no replication. I cannot see how making it
synchronous would change thoughput, as it only induces waiting time on
the clients, but no extra work. I can only assume the test didn't use
enough clients to saturate the hardware under high-latency situations,
or clients were somehow experiencing application-specific contention.
Thank you for your experience and opinion.
The workload is TPC-C-like write-heavy one; DBT-2. They compared the
throughput of synchronous replication case against that of no replication
case.
Today, they told me that they ran the test on two virtual machines on a
single physical machine. They also used pgpool-II in both cases. In
addition, they may have ran the applications and pgpool-II on the same
virtual machine as the database server.
It sounded to me that the resource is so scarce that concurrency was low, or
your assumption may be correct. I'll hear more about their environment from
them.
BTW it's pity that I cannot find any case study of performance of the
flagship feature of PostgreSQL 9.0/9.1, streaming replication...
Regards
MauMau
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
