Re: long transfer time for binary data - Mailing list pgsql-general

From Andy Colson
Subject Re: long transfer time for binary data
Date
Msg-id 56A0438D.6090903@squeakycode.net
Whole thread Raw
In response to long transfer time for binary data  (Johannes <jotpe@posteo.de>)
Responses Re: long transfer time for binary data
List pgsql-general
On 01/20/2016 03:29 PM, Johannes wrote:
> I noticed transferring a large object or bytea data between client and
> server takes a long time.
> For example: An image with a real size of 11 MB could be read on server
> side (explain analyze) in 81ms. Fine.
>
> But on client side the result was completed after 6.7 seconds without
> ssl compression and 4.5 seconds with ssl compression (both via 100MBit
> ethernet).
>
> SSL compression seems to be not a good idea anymore, since this had
> become a security risk. Its still possible with pgadmin, but afaik not
> with java/jdbc .
>
> Are there any other solutions available to display my images in my
> client application more quickly? Or are there planned improvements to
> postgresql (transferring the real binary data)?
>
> Best regards
> Johannes
>

Yep, that's slow.  The ssl compression is very odd if the image is jpeg'ish and already compressed.  If its a bitmap or
uncompressedtif then its not so surprising. 

A few tests you could try:

1) copy the same 11 meg file from server to client via regular file copy and time it.  At 100 Mbit/s it should take
abouta second.  If it takes 6 you have network problems, not PG problems. 

2) try it via psql command line (or at least something other than java), to see if its java thats the problem.

3) watch wireshark/tcpdump, maybe you'll see something glaring that'll point you in the right direction.

-Andy

PS: I've never heard that ssl compression was a security risk, got links/proof?


pgsql-general by date:

Previous
From: "(Daniel Stolf)"
Date:
Subject: adding a bdr node using bcv backup
Next
From: Craig Ringer
Date:
Subject: Re: adding a bdr node using bcv backup