Re: [PERFORM] Client Server performance & UDS - Mailing list pgsql-performance
| From | Kevin.Hughes@uk.fujitsu.com |
|---|---|
| Subject | Re: [PERFORM] Client Server performance & UDS |
| Date | |
| Msg-id | da3dc4593d12498187a6429e39340185@R01UKEXCASM123.r01.fujitsu.local Whole thread Raw |
| In response to | Re: [PERFORM] Client Server performance & UDS (Rick Otten <rottenwindfish@gmail.com>) |
| Responses |
Re: [PERFORM] Client Server performance & UDS
|
| List | pgsql-performance |
Hi Rick thanks for the reply.
Our aim is to minimise latency hence we have a dedicated 1:1 relationship between the client and the server. If I use connection pooling surely this introduced latency – getting a server from the pool establishing the connection?
Am I missing something?
From: Rick Otten [mailto:rottenwindfish@gmail.com]
Sent: 27 May 2017 13:27
To: Hughes, Kevin <Kevin.Hughes@uk.fujitsu.com>
Cc: pgsql-performa. <pgsql-performance@postgresql.org>
Subject: Re: [PERFORM] Client Server performance & UDS
You should have a layer such as pgbouncer between your pg instance and your application. It is designed to mitigate the access latency issues you describe.
On May 26, 2017 10:03 AM, "Kevin.Hughes@uk.fujitsu.com" <Kevin.Hughes@uk.fujitsu.com> wrote:
Hi,
This is a general question around this performance area rather than a specific performance problem.....so I apologise now for a lack of a specific detail.
We have an application that does many small actions on the DB – and it’s a small DB (a 50/100 Mbytes) so we would expect it to be contained in memory. Accesses need to be low latency – unfortunately there are “serial” accesses where the result of one access governs the next. Luckily the work to be done by the DB is, we believe, very simple and hence fast. Everything is running on one (large) server so we use UDS to connect the client to the server.
Out observation (suspicion) is that the latency of the access, as opposed to the cost of the query, is high. Having done some investigation we believe the UDS latency may be contributing AND the cost imposed by postgres in “formatting” the messages between the client and server (transformation to network format?).
We will try and get underneath this with real results/measurements but I would appreciate any comments pointers on what we are doing and how/if we can optimise this style of applications
Cheers
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
pgsql-performance by date: