[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] publicdb.gnumed.de performance
From: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] publicdb.gnumed.de performance |
Date: |
Thu, 16 Jun 2011 13:06:18 +0200 |
User-agent: |
KMail/1.13.7 (Linux/2.6.38.4-23-desktop; KDE/4.6.4; i686; ; ) |
Am Donnerstag, 16. Juni 2011, 11:50:25 schrieb Karsten Hilbert:
> On Thu, Jun 16, 2011 at 11:33:01AM +0200, Hilbert, Sebastian wrote:
> > Initials research indicates that performance is connected to network
> > latency rather then speed.
> >
> > It is a good sign that there are not too many queries but each one is
> > affecting performance.
>
> Sure. But we can't cut it down to less than one query. We
> are already caching readonly connections (which is the large
> majority of our queries) so connection setup time should not
> play a measurable role. Be that as it may, psycopg2 has
> removed a bunch of useless stuff from connection setup so
> that this will be even faster. Unfortunately, the Debian
> package maintainer seems to be occupied with other things
> for quite a while already failing to provider up to date
> packages.
>
> > There are two parts to this. The request time and the payload size.
>
> Payload size should be near negligible AFAICT (and
> unavoidable in any case). It'd be good to estimate that
> with, say, wireshark though.
Apart from all technical details we had some measurements where Jim and
Rogerio provided feedback.
It looked like the time waiting for patient data to appear following a search
was pretty much connected to the raw ping times.
That made me think there were a lot of individual requests involved.
To dig deeper one would have to write a test program with a fixed use case and
known number of connections.
In the case we are talking about here it would be interesting to compare the
public database and Marc's "public/home server". Despite the fact that Marc's
server is in the same city all traffic get routed through Frankfurt or other
big hubs. Can't reduce this I would assume.
http://postgresql.1045698.n5.nabble.com/Slow-query-execution-over-high-
latency-network-td3392242.html
>
> Karsten