From: Fujii Masao masao.fu...@gmail.com
Though I cannot show the detail for some reasons, as far as I measured
the performance overhead of sync rep by using pgbench, the overhead of
throughput was less than 10%. When measuring sync rep, I used two
set of physical machine and storage for the
From: Claudio Freire klaussfre...@gmail.com
On Wed, May 9, 2012 at 7:34 PM, MauMau maumau...@gmail.com 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.
On 10 Květen 2012, 13:34, MauMau wrote:
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
On Wed, May 9, 2012 at 5:34 PM, MauMau maumau...@gmail.com 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
From: Tomas Vondra t...@fuzzy.cz
There were some nice talks about performance impact of sync rep, for
example this one:
http://www.2ndquadrant.com/static/2quad/media/pdfs/talks/SyncRepDurability.pdf
There's also a video:
http://www.youtube.com/watch?v=XL7j8hTd6R8
Thanks. The video is
On Thu, May 10, 2012 at 8:34 PM, MauMau maumau...@gmail.com wrote:
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
On Wed, May 9, 2012 at 8:06 AM, MauMau maumau...@gmail.com wrote:
Hello,
I've heard from some people that synchronous streaming replication has
severe performance impact on the primary. They said that the transaction
throughput of TPC-C like benchmark (perhaps DBT-2) decreased by 50%. I'm
On Wed, May 9, 2012 at 3:58 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, May 9, 2012 at 8:06 AM, MauMau maumau...@gmail.com wrote:
I've heard from some people that synchronous streaming replication has
severe performance impact on the primary. They said that the transaction
throughput
On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
shortcut...@googlemail.com wrote:
I am not sure whether the replicant can be triggered to commit to disk
before the commit to disk on the master has succeeded; if that was the
case there would be true serialization = 50%.
This sounds like it
On Wed, May 9, 2012 at 5:45 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
shortcut...@googlemail.com wrote:
I am not sure whether the replicant can be triggered to commit to disk
before the commit to disk on the master has succeeded; if that
On Wed, May 9, 2012 at 12:03 PM, Robert Klemme
shortcut...@googlemail.com wrote:
On Wed, May 9, 2012 at 5:45 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
shortcut...@googlemail.com wrote:
I am not sure whether the replicant can be triggered to
From: Merlin Moncure mmonc...@gmail.com
On Wed, May 9, 2012 at 8:06 AM, MauMau maumau...@gmail.com wrote:
Hello,
I've heard from some people that synchronous streaming replication has
severe performance impact on the primary. They said that the transaction
throughput of TPC-C like benchmark
On Wed, May 9, 2012 at 7:34 PM, MauMau maumau...@gmail.com wrote:
I can't speak for other databases, but it's only natural to assume
that tps must drop. At minimum, you have to add the latency of
communication and remote sync operation to your transaction time. For
very short transactions
13 matches
Mail list logo
