Michael Fuhr wrote:
> On Fri, Sep 15, 2006 at 09:52:04AM -0600, Michael Fuhr wrote:
>> On Fri, Sep 15, 2006 at 05:37:50PM +0200, zeljko wrote:
>> > But, when I try (via tunnel, explained above)
>> > psql -p 5400 -h localhost mydatabase
>> > it connects and works fine, but there's no compression.
>> > Query returns in cca 20 seconds, almost same (maybe 0.5 sec. different)
>> > as normal psql connection.Conclusion is that there's no compression of
>> > psql stream. Returned data is varchars and integers.
>>
>> That's a tenuous conclusion; it assumes that the data transfer is
>> what's taking all the time. Query planning and execution and
>> client-side processing must also be taken into account. Using a
>> sniffer to observe the amount of data transferred would be a more
>> appropriate test.
>
> Also, don't discount the amount of time that compressing and
> decompressing takes. The ls and psql tests aren't necessarily
> comparable due to differing amounts and characteristics of data.
>
> I just ran some tests between a couple of boxes on a local network,
> using psql over a tunneled ssh connection as you are. A sniffer
> showed that a compressed connection transferred 54% of the amount
> of data as an uncompressed connection but it took 69% longer to do
> so. If the network is fast and the boxes are slow then a compressed
> connection can be a net loser.
>
I'm testing over DSL line (test server have 256k Upload and 1MB download).
Results are based on this connection.
Server : PIV 3Ghz HT, 1GB RAM. (DSL D 1MB U 256k)
Client : PIV 3Ghz HT, 1GB RAM. (DSL D 3MB U 384k).
nTier results shows real compression (faster more than twice).
