From: | Clemens Eisserer <linuxhippy(at)gmail(dot)com> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Slow query execution over WAN network |
Date: | 2011-02-25 20:46:00 |
Message-ID: | AANLkTin1o3o80eDc9hb+2jp+A43iYPJ_WkWeoXUbbOVp@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Hi,
> I only see the query taking 400ms or so in the wireshark capture you
> attached, so I assume this the DSL case?
Right, this was the DSL case.
> In the DSL case it takes around ~230ms just to get the query to the server
> (this is about right for an upstream data rate of ~400-500Kbit); then the
> query itself takes ~80ms to execute (seems high, but it's hard to break that
> latency down into query execution vs. network latency); then ~105ms to get
> the results back to the client, which is a data rate of around 2.2Mbit. TCP
> is probably still in slow-start too, which won't be helping.
>
> I would guess that the UMTS case is so much worse because of a combination
> of higher base latency + slower data rates.
You are right - it was really a bandwith issue, especially with UMTS
were upload is extremly slow.
Port-Forewarded over a compressed ssh-tunnel brought the time down to
about 1/8 - instead of 2000ms the query executes in ~220ms - and ssh
statistics report data was compressed down to ~10-15%.
This is great news, without any code-changes I can push response
latencies back to an acceptable value =)
Thanks a lot, Clemens
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Fowler | 2011-02-28 10:23:17 | Re: Failing test in org.postgresql.test.jdbc2.DateTest |
Previous Message | Maciek Sakrejda | 2011-02-25 16:22:46 | Re: difference on execution time between prepared statement in pgAdmin and through JDBC Stack |