Re: testing HS/SR - 1 vs 2 performance - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: testing HS/SR - 1 vs 2 performance
Date
Msg-id 4BCE6C77.6060909@catalyst.net.nz
Whole thread Raw
In response to Re: testing HS/SR - 1 vs 2 performance  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: testing HS/SR - 1 vs 2 performance  (Robert Haas <robertmhaas@gmail.com>)
Re: testing HS/SR - 1 vs 2 performance  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Robert Haas wrote:
>
> So, does anyone have a few cycles to test this out?  We are down to
> handful of remaining open items, so getting this tested and committed
> sooner = beta sooner.
>
>
>   

I did some testing of this patch (v2). Unfortunately I don't have access 
to hardware capable of doing tests at the same scale as Erik used. 
However I was still able to show a consistent difference (I think) 
between standby performance with and without the patch applied.

Setup:

host: 2.7 Ghz dual core amd64 with 4G ram and 1 sata drive,
code: cvs head from 2010-04-14.
pgbench:  scale=100, 4 clients, 10000 (select) transactions each.

Results:

Master performance (with and without patch applied ):
tps = 10903.612340 - 14070.109951 (including connections establishing)

Standby performance without patch (:
tps = 8288.119913 - 9722.245178 (including connections establishing)

Standby performance with patch applied:
tps = 11592.922637 - 14065.553214 (including connections establishing)

I performed 8 runs of each, and results would start at the low range and 
climb up to the high one, where they would stabilize. In between runs I 
cleared the os buffer cache and (partially) reloaded it by selecting 
counts from the pgbench tables (i.e I was trying to ensure each run had 
the same or similar os cache contents).

Overall looks like the patch gets standby read only performance close to 
the master - at least in the case where there are minimal master 
transactions being tracked by the standby (I had to leave the master 
idle whilst running the standby case, as they shared the machine). Hope 
this info is useful.

regards

Mark



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Should database = all in pg_hba.conf match a replication connection?
Next
From: Tom Lane
Date:
Subject: Re: Should database = all in pg_hba.conf match a replication connection?