gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]