<div dir="ltr"><div><div><div>I think the -C option was my issue. You're right, that is a more realistic method that will be being used and I'm seeing things act more consistently now.<br><br></div>With pgpool:<br><br>kfiske@pgpool-base:~$ pgbench -c 20 -j 10 -T 300 -C -S pgbench<br>Password: <br>starting vacuum...end.<br>transaction type: SELECT only<br>scaling factor: 1000<br>query mode: simple<br>number of clients: 20<br>number of threads: 10<br>duration: 300 s<br>number of transactions actually processed: 2217400<br>latency average: 2.706 ms<br>tps = 7391.287680 (including connections establishing)<br>tps = 115036.308523 (excluding connections establishing)<br><br></div>Without pgpool (connecting directly to master from pgpool system)<br><br>kfiske@pgpool-base:~$ pgbench -h db01 -c 20 -j 10 -T 300 -C -S pgbench<br>Password: <br>starting vacuum...end.<br>transaction type: SELECT only<br>scaling factor: 1000<br>query mode: simple<br>number of clients: 20<br>number of threads: 10<br>duration: 300 s<br>number of transactions actually processed: 113890<br>latency average: 52.682 ms<br>tps = 373.709111 (including connections establishing)<br>tps = 17966.912516 (excluding connections establishing)<br><br></div>Arigatou gozaimasu :)<br><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Keith Fiske<br>Database Administrator<br>OmniTI Computer Consulting, Inc.<br><a href="http://www.keithf4.com" target="_blank">http://www.keithf4.com</a></div></div>
<br><div class="gmail_quote">On Tue, Jan 20, 2015 at 5:59 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"-C" simulates more real world like environment: client needs to<br>
connect to DB server every time starting a session. So performance<br>
dropping is expected. Also you need to run pgbench with -C against<br>
PostgreSQL to get an apple-t-apple comparison. which I expect huge<br>
performance dropping because the overhead to start a session in<br>
PostgreSQL is pretty high. One of the reason why pgpool was born is to<br>
solve the problem.<br>
<div class="HOEnZb"><div class="h5"><br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
> Still confused by these results.<br>
><br>
> I turned connection caching back on in pgpool and used the -C option to<br>
> pgbench with the following result. tps seems on par with just doing a<br>
> direct connection to the master, but only if the connection establishment<br>
> is excluded. Included, it's pretty horrible.<br>
><br>
> kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S -C pgbench<br>
> Password:<br>
> starting vacuum...end.<br>
> transaction type: SELECT only<br>
> scaling factor: 1000<br>
> query mode: simple<br>
> number of clients: 20<br>
> number of threads: 10<br>
> duration: 300 s<br>
> number of transactions actually processed: 2217927<br>
> latency average: 2.705 ms<br>
> tps = 7393.042019 (including connections establishing)<br>
> tps = 119967.718643 (excluding connections establishing)<br>
><br>
> Running again without -C and back to the performance being halved<br>
><br>
> kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S pgbench<br>
> Password:<br>
> starting vacuum...end.<br>
> transaction type: SELECT only<br>
> scaling factor: 1000<br>
> query mode: simple<br>
> number of clients: 20<br>
> number of threads: 10<br>
> duration: 300 s<br>
> number of transactions actually processed: 15227370<br>
> latency average: 0.394 ms<br>
> tps = 50757.799330 (including connections establishing)<br>
> tps = 50760.275039 (excluding connections establishing)<br>
><br>
><br>
><br>
> --<br>
> Keith Fiske<br>
> Database Administrator<br>
> OmniTI Computer Consulting, Inc.<br>
> <a href="http://www.keithf4.com" target="_blank">http://www.keithf4.com</a><br>
><br>
> On Mon, Jan 19, 2015 at 6:05 PM, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>> wrote:<br>
><br>
>> If you want to test the effect of connection caching, you should turn<br>
>> on -C option of pgbench.<br>
>><br>
>> Best regards,<br>
>> --<br>
>> Tatsuo Ishii<br>
>> SRA OSS, Inc. Japan<br>
>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> Japanese:<a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>><br>
>> > Evaluating pgpool for a client as a load balancer and running into some<br>
>> > unexpected performance degradation. Using pg_bench, read-only selects are<br>
>> > going half as fast through pgpool as they are going directly to the<br>
>> master<br>
>> > system. Does not seem to be a network issue between the pgpool server and<br>
>> > the databases since connecting directly to either the master or the slave<br>
>> > from the pgpool server works fine.<br>
>> ><br>
>> > I saw this issue on the list archive<br>
>> > <a href="http://www.sraoss.jp/pipermail/pgpool-general/2015-January/003438.html" target="_blank">http://www.sraoss.jp/pipermail/pgpool-general/2015-January/003438.html</a><br>
>> > but I'm not in a position right now to be testing a patched version on<br>
>> > their systems. I tried turning off connection caching and doing the<br>
>> kernel<br>
>> > tuning as mentioned in that email. The first kernel tuning parameter<br>
>> > doesn't seem to exist for this system (Ubuntu 12.04) and changing the<br>
>> other<br>
>> > two didn't seem to make any difference.<br>
>> ><br>
>> > If anyone has any other suggestions for what to look at, I'd appreciate<br>
>> it.<br>
>> > The only thing pgpool is being used for is load balancing and connection<br>
>> > pooling. All other options are turned off.<br>
>> ><br>
>> > SELECT directly from master from the pgpool server but not using pgpool<br>
>> > kfiske@pgpool-base:/etc/pgpool2$ pgbench -h db01 -c 20 -j 10 -T 300 -S<br>
>> > pgbench<br>
>> > Password:<br>
>> > starting vacuum...end.<br>
>> > transaction type: SELECT only<br>
>> > scaling factor: 1000<br>
>> > query mode: simple<br>
>> > number of clients: 20<br>
>> > number of threads: 10<br>
>> > duration: 300 s<br>
>> > number of transactions actually processed: 33780221<br>
>> > latency average: 0.178 ms<br>
>> > tps = 112600.544120 (including connections establishing)<br>
>> > tps = 112610.109694 (excluding connections establishing)<br>
>> ><br>
>> ><br>
>> > SELECT directly from slave from the pgpool server but not using pgpool<br>
>> > kfiske@pgpool-base:/etc/pgpool2$ pgbench -h db02 -c 20 -j 10 -T 300 -S<br>
>> > pgbench -n<br>
>> > Password:<br>
>> > transaction type: SELECT only<br>
>> > scaling factor: 1000<br>
>> > query mode: simple<br>
>> > number of clients: 20<br>
>> > number of threads: 10<br>
>> > duration: 300 s<br>
>> > number of transactions actually processed: 30087965<br>
>> > latency average: 0.199 ms<br>
>> > tps = 100293.060878 (including connections establishing)<br>
>> > tps = 100302.790535 (excluding connections establishing)<br>
>> ><br>
>> ><br>
>> > SELECT only from pgpool (to ensure load-balancing works)<br>
>> > kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S pgbench<br>
>> > Password:<br>
>> > starting vacuum...end.<br>
>> > transaction type: SELECT only<br>
>> > scaling factor: 1000<br>
>> > query mode: simple<br>
>> > number of clients: 20<br>
>> > number of threads: 10<br>
>> > duration: 300 s<br>
>> > number of transactions actually processed: 14781236<br>
>> > latency average: 0.406 ms<br>
>> > tps = 49270.616847 (including connections establishing)<br>
>> > tps = 49273.323274 (excluding connections establishing)<br>
>> ><br>
>> > --<br>
>> > Keith Fiske<br>
>> > Database Administrator<br>
>> > OmniTI Computer Consulting, Inc.<br>
>> > <a href="http://www.keithf4.com" target="_blank">http://www.keithf4.com</a><br>
>><br>
</div></div></blockquote></div><br></div>