Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEFpc-00024f-V6 for pgsql-performance@arkaria.postgresql.org; Fri, 26 May 2017 14:03:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dEFpc-0002Gp-Hv for pgsql-performance@arkaria.postgresql.org; Fri, 26 May 2017 14:03:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dEFpc-0002Gg-43 for pgsql-performance@postgresql.org; Fri, 26 May 2017 14:03:08 +0000 Received: from mail1.bemta5.messagelabs.com ([195.245.231.145]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dEFpU-0007EQ-6o for pgsql-performance@postgresql.org; Fri, 26 May 2017 14:03:07 +0000 Received: from [85.158.136.83] by server-9.bemta-5.messagelabs.com id 06/92-01999-19538295; Fri, 26 May 2017 14:02:57 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRWlGSWpSXmKPExsViZ8MRojvRVCP SYMpjEYvrM88xOzB6XNg3jT2AMYo1My8pvyKBNaOl9SFbwUXNilerupkbGPeodDFycQgJrGGS +HD1BRuEc4xR4l37MWYI5yKjRNeER6xdjJwcbAKOEsfXzWMHsUUEPCVm79/G0sXIwSEsoCHxc xUXRFhX4vLxu1AlehJLf71lAylhEVCVmL+uCCTMK+Av0XrkKzOIzSggK/GlcTWYzSwgLnHryX wmEFtCQEBiyZ7zzBC2qMTLx/9YIWwDia1L97FA2AoSt2YcZYXozZN4uOEBI8R8QYmTM5+wTGA UmoVk7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjOrFqUVlqUW6lnpJRZnp GSW5iZk5uoYGpnq5qcXFiempOYlJxXrJ+bmbGIHRwgAEOxjXtjofYpTkYFIS5Z2+Tj1SiC8pP 6UyI7E4I76oNCe1+BCjDAeHkgRvk4lGpJBgUWp6akVaZg4wbmHSEhw8SiK89UZAad7igsTc4s x0iNQpRkUpcV4fkD4BkERGaR5cGyxVXGKUlRLmZQQ6RIinILUoN7MEVf4VozgHo5Iwb5sx0BS ezLwSuOmvgBYzAS32PacOsrgkESEl1cBY7vFJ7Vfq86TVcYKLV31fYuGd/WrDir+yM399ZI3S Xfs8Y2dMau3RH0E837rXV1VGXmwvyNp5RWmS9BEJF8HsGwdEDkxzPrrygmz/ns3/dzYbv9Asu zntQ96xs2qhN+QOdrleqmqrcpn/O3rHge5ldq9X2c56fvt1/H8Po9nL4nY6FzdyZO5QUGIpzk g01GIuKk4EAJkc9dsQAwAA X-Env-Sender: Kevin.Hughes@uk.fujitsu.com X-Msg-Ref: server-5.tower-36.messagelabs.com!1495807377!100429349!1 X-Originating-IP: [62.60.8.84] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=uk.fujitsu.com,-,- X-VirusChecked: Checked Received: (qmail 31887 invoked from network); 26 May 2017 14:02:57 -0000 Received: from unknown (HELO mailhost3.uk.fujitsu.com) (62.60.8.84) by server-5.tower-36.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 26 May 2017 14:02:57 -0000 Received: from R01UKEXCASM126.r01.fujitsu.local (ex2k13_126.fs.fujitsu.com [10.183.43.178]) by mailhost3.uk.fujitsu.com (8.14.5/8.14.5) with ESMTP id v4QE2SsH031741 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 26 May 2017 15:02:44 +0100 Received: from R01UKEXCASM123.r01.fujitsu.local (10.183.43.175) by R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 26 May 2017 15:02:41 +0100 Received: from R01UKEXCASM123.r01.fujitsu.local ([fe80::10cc:f386:59a7:5fa9]) by R01UKEXCASM123.r01.fujitsu.local ([fe80::10cc:f386:59a7:5fa9%23]) with mapi id 15.00.1263.000; Fri, 26 May 2017 15:02:40 +0100 From: "Kevin.Hughes@uk.fujitsu.com" To: "pgsql-performance@postgresql.org" Subject: Client Server performance & UDS Thread-Topic: Client Server performance & UDS Thread-Index: AdLWJrtPejTnl46eTAud8dh5PEb2+Q== Date: Fri, 26 May 2017 14:02:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.182.185.7] Content-Type: multipart/alternative; boundary="_000_d9852308baee4c33aa11b4b1d33c8dc3R01UKEXCASM123r01fujits_" MIME-Version: 1.0 X-Pg-Spam-Score: -4.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 --_000_d9852308baee4c33aa11b4b1d33c8dc3R01UKEXCASM123r01fujits_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a general question around this performance area ra= ther 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 co= ntained in memory. Accesses need to be low latency - unfortunately there a= re "serial" accesses where the result of one access governs the next. Luck= ily 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 bel= ieve 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 w= ould appreciate any comments pointers on what we are doing and how/if we c= an optimise this style of applications Cheers Unless otherwise stated, this email has been sent from Fujitsu Services Li= mited (registered in England No 96056); Fujitsu EMEA PLC (registered in En= gland No 2216100) both with registered offices at: 22 Baker Street, London= W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fuji= tsu Laboratories of Europe Limited (registered in England No. 4153469) bot= h with registered offices at: Hayes Park Central, Hayes End Road, Hayes, M= iddlesex, UB4 8FE.=20 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 g= uarantee that this email has not been intercepted and amended or that it i= s virus-free. --_000_d9852308baee4c33aa11b4b1d33c8dc3R01UKEXCASM123r01fujits_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

        &nb= sp;       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.

 

        &nb= sp;       We have an application that does m= any small actions on the DB – and it’s a small DB (a 50/100 Mb= ytes) 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 t= o be done by the DB is, we believe,  very simple and hence fast. Ever= ything is running on one (large) server so we use UDS to connect the clien= t to the server.

 

Out observation (suspicion) is that the latency of&= nbsp; the access, as opposed to the cost of the query, is high. Having don= e 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 for= mat?).

 

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

 

 

Cheers

 

 

 

 


Unless otherwise stated, this email has been sent from Fujitsu Services Li= mited (registered in England No 96056); Fujitsu EMEA PLC (registered in En= gland No 2216100) both with registered offices at: 22 Baker Street, London= W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fuji= tsu Laboratories of Europe Limited (registered in England No. 4153469) bot= h with registered offices at: Hayes Park Central, Hayes End Road, Hayes, M= iddlesex, 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 g= uarantee that this email has not been intercepted and amended or that it i= s virus-free.
--_000_d9852308baee4c33aa11b4b1d33c8dc3R01UKEXCASM123r01fujits_--