[pgpool-general: 3997] Re: accept() scalability issues
michael.renner at amd.co.at
Fri Aug 21 18:27:24 JST 2015
> On 21 Aug 2015, at 00:50, Tatsuo Ishii <ishii at postgresql.org> wrote:
> I was hoping to see imporvements in pgbench -C or similar use case
> (for example ab), which shows the connection overhead from client to
Sorry, we don’t have any systems suitable for benchmarking - no free spare metal and the VM hosts are all pretty loaded.
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.
This is corroborated in this graph: http://i.imgur.com/d0IafG0.png <http://i.imgur.com/d0IafG0.png>
It shows the average SQL query runtime of a PHP application without connection pooling - each request will create a new database connection.
mean_90 shows the truncated mean value after the top 10% of the query runtimes have been removed
upper_90 shows shows the 90th percentile of the query runtimes
See https://github.com/etsy/statsd/pull/499/files <https://github.com/etsy/statsd/pull/499/files> for thorough explanation of the values
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)
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pgpool-general