<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Aug 2015, at 00:50, Tatsuo Ishii &lt;<a href="mailto:ishii@postgresql.org" class="">ishii@postgresql.org</a>&gt; wrote:</div><div class=""><br class="">I was hoping to see imporvements in pgbench -C or similar use case<br class="">(for example ab), which shows the connection overhead from client to<br class="">pgpool-II.<br class=""></div></blockquote><div><br class=""></div>Sorry, we don’t have any systems suitable for benchmarking - no free spare metal and the VM hosts are all pretty loaded.</div><div><br class=""></div><div>The measurement that will improve the most is latency since there are much fewer context switches and CPU load, meaning that the time between completed TCP handshake and a pgpool child being attached to the socket is noticeably lower.</div><div><br class=""></div><div>This is corroborated in this graph:&nbsp;<a href="http://i.imgur.com/d0IafG0.png" class="">http://i.imgur.com/d0IafG0.png</a></div><div><br class=""></div><div>It shows the average SQL query runtime of a PHP application without connection pooling - each request will create a new database connection.</div><div><br class=""></div><div>mean_90 shows the truncated mean value after the top 10% of the query runtimes have been removed</div><div>upper_90 shows shows the 90th percentile of the query runtimes</div><div><br class=""></div><div>See&nbsp;<a href="https://github.com/etsy/statsd/pull/499/files" class="">https://github.com/etsy/statsd/pull/499/files</a>&nbsp;for thorough explanation of the values</div><div><br class=""></div><div>The ~0.5ms - 1ms drop in mean_90 is most likely the saved connection overhead, the lowered upper_90 hints that there were cases where the overall system load had adverse effects on some queries (e.g. pgpool processes not being scheduled on a CPU in time)</div><div><br class=""></div><div>Since the amount of TPS of single processes is directly related to system latency we probably doubled the TPS of our system (2ms to 1ms) - the maximum achievable throughput of the system has massively increased due to the lowered CPU utilisation.</div><div><br class=""></div><div><br class=""></div><div>Hope this suffices, if you absolutely need synthetic pgbench runs I’d have to check if we can decommission a few systems to have a proper testing environment.</div><div><br class=""></div><div><br class=""></div><div>best,</div><div>Michael</div></body></html>