Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEapc-00083s-Jp for pgsql-performance@arkaria.postgresql.org; Sat, 27 May 2017 12:28:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dEapb-0002Ee-Bb for pgsql-performance@arkaria.postgresql.org; Sat, 27 May 2017 12:28:31 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dEanp-0007Yv-9H for pgsql-performance@postgresql.org; Sat, 27 May 2017 12:26:41 +0000 Received: from mail-qk0-x231.google.com ([2607:f8b0:400d:c09::231]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dEanh-00045A-Jx for pgsql-performance@postgresql.org; Sat, 27 May 2017 12:26:39 +0000 Received: by mail-qk0-x231.google.com with SMTP id k74so23756035qke.1 for ; Sat, 27 May 2017 05:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DoaRrfMoiCe+cEeTPT4rBR8TVZfWmLUKe4eFEq0bonc=; b=DP5jq94zpQ/3kzRQeif7qNk370aM48+ruVJk1VxqfyZSqArzABQXLtTINaH8DtSeAo BuUszJG6N/JRPDkJu3w6AMUc1r3FZL4yOFS2070HxOAH1Wp5VAFOnJVzONBW8WdNwQbN MCfrqUv4L7b4VC5tpV9aANVQBp/wX6QQhQkd/wlo44yAFw1rGabfgRqaBSC7xJsvimV1 Hplg8HPqbsywN3w1YcmKz6N1vYOmb8EAXAv+WDxYjwWBqQLIwz1xUJ0eTqqz3qJUrlKk VL9q6UdM/T4+Kdu4QHBzHMa/cp3TvV3H08daUhRIXM50zDrWLkhX7rFr40LQM/cIYgRo T8yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DoaRrfMoiCe+cEeTPT4rBR8TVZfWmLUKe4eFEq0bonc=; b=fyN3BE5Is9xzc8UBukMqHJp0jm458HdKIFjDD37o3vXzIQ+PZZ+gyi72xIqy3yPjCi /9NO3igDm1nbUuDctlxEjMBQQbfrjJl1oTbM/GNXj2ePIWFULOVlPpeEnPfzdo0WL7h1 aDdf1CE3uIEtiMfLmAX5pQrkrMrNWX6rOG3hv0r/WgUrT6Ap0CHVcDVT+oLBlnlPBLVy DbuFDPCBb93C35qISOOLmQR/jhUs86k97qCxfV6JdrF5ci2e01N+6d8EV7CiIpVT/L0H HJf7ZCoRtdesMTfYiuogqanS5cmp6SMyOnNkx1tFHTuAQzpc3fZFZyR7UjbFuKKzKIfu sNWQ== X-Gm-Message-State: AODbwcBB+LEhe8SqPSemyYP2eYRlpxorjMwMfxPUYPg5vHS2tvMw47Qm CFmCOwBf6Yh2V8wHrLpR4CSTKqfM4Q== X-Received: by 10.55.187.196 with SMTP id l187mr7424265qkf.185.1495887992400; Sat, 27 May 2017 05:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.164.228 with HTTP; Sat, 27 May 2017 05:26:31 -0700 (PDT) Received: by 10.12.164.228 with HTTP; Sat, 27 May 2017 05:26:31 -0700 (PDT) In-Reply-To: References: From: Rick Otten Date: Sat, 27 May 2017 08:26:31 -0400 Message-ID: Subject: Re: Client Server performance & UDS To: Kevin.Hughes@uk.fujitsu.com Cc: "pgsql-performa." Content-Type: multipart/alternative; boundary="94eb2c0493346933270550809048" X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --94eb2c0493346933270550809048 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 th= e > DB =E2=80=93 and it=E2=80=99s a small DB (a 50/100 Mbytes) so we would ex= pect it to be > contained in memory. Accesses need to be low latency =E2=80=93 unfortunat= ely there > are =E2=80=9Cserial=E2=80=9D accesses where the result of one access gove= rns 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 oppose= d > 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 =E2=80=9Cformatting=E2=80=9D 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) an= d > Fujitsu Laboratories of Europe Limited (registered in England No. 4153469= ) > both with registered offices at: Hayes Park Central, Hayes End Road, Haye= s, > Middlesex, UB4 8FE. > This email is only for the use of its intended recipient. Its contents ar= e > 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. > --94eb2c0493346933270550809048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You should have a layer such as pgbouncer between your pg= instance and your application.=C2=A0 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> wro= te:

Hi,

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is a general question around t= his performance area rather than a specific performance problem.....so I ap= ologise now for a lack of a specific detail.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We have an application that does ma= ny small actions on the DB =E2=80=93 and it=E2=80=99s a small DB (a 50/100 = Mbytes) so we would expect it to be contained in memory. Accesses need to b= e low latency =E2=80=93 unfortunately there are =E2=80=9Cserial=E2=80=9D ac= cesses where the result of one access governs the next. Luckily the=C2=A0 work to= be done by the DB is, we believe, =C2=A0very simple and hence fast. Everyt= hing is running on one (large) server so we use UDS to connect the client t= o the server.

=C2=A0

Out observation (suspicion) is that the latency of= =C2=A0 the access, as opposed to the cost of the query, is high. Having don= e some investigation=C2=A0 we believe the UDS latency may be contributing A= ND the cost imposed by postgres in =E2=80=9Cformatting=E2=80=9D the messages between the client and server (transformation to network form= at?).

=C2=A0

We will try and get underneath this with real result= s/measurements but I would appreciate any comments pointers on what we are = doing and how/if we can optimise this style of applications

=C2=A0

=C2=A0

Cheers

=C2=A0

=C2=A0

=C2=A0

=C2=A0


Unless otherwise stated, this email has been sent from Fujitsu Services Lim= ited (registered in England No 96056); Fujitsu EMEA PLC (registered in Engl= and No 2216100) both with registered offices at: 22 Baker Street, London W1= U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu = Laboratories of Europe Limited (registered in England No. 4153469) both wit= h registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middles= ex, 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 gua= rantee that this email has not been intercepted and amended or that it is v= irus-free.
--94eb2c0493346933270550809048--