gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] low performance when working from remote server


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] low performance when working from remote server
Date: Thu, 3 Jun 2004 20:20:57 +0200
User-agent: KMail/1.6.1

On Thursday 03 June 2004 19:50, Hilmar Berger wrote:
> Hi all,
>
> I just tried to work from the public gnumed-db at anubis.homeunix.com.
Try again with hherb.com. It is a lot faster. Not nearly as fast as a local 
server but faster.
> Responsiveness was horribly bad, it took ages to get all the modules loaded
> an to go from one notebook tab to the next one. Just to get an idea what
> might the reason for this behaviour I ran ethereal and captured the switch
> from the documents to the lab-journal page.
Lab journal is definetly not the best example for general Gnumed application 
speed but your are right there are issues.
> It took about 160s (or 2min 40 
> secs) and needed about 1500 packets to send and receive. This makes about
> 10 packets/second and a mean packet travel time of 100ms. Packet size was
> mostly below 100 bytes.The travel time seems to be what one would expect
> from a internet link. In an intranet, I would expect packet travel times of
> about 1-3ms, so this would mean that you will have to spend about 1.5-4s
> for a network traffic only.
Fetching records from my local database pretty much scales. 

1000 unreviewed lab requests 
more_avail, unreviewed_results = gmPathLab.get_unreviewed_results(limit=1000)
16seconds

50 items ca 0,79sec for fetching only.

> Add to this 1-2 s for data retrieval on backend 
> side if the database holds a lot of data and you get between 2-6 seconds to
I'd say even more depending on your computer.
> switch from one tab to the next. If these figures is correct I would say
> that gnumed will be quit slow to work with. Is there anything we can do
> about ?
Little do I know but yes and no. We can optimize code here and there. We can 
hide slow application behavior here and there with prefetching, lazy loading, 
on demand loading and so forth. 
You can get yourself the newest python. Python 2.3 is around 20% faster than 
2.2 in some areas. 
Get yourself a faster computer/server :-)
I don't have access to a 3GHz PC but I expect Gnumed to run a bit faster than 
on my 1GHz Notebook.
Lastly there are some projects to convert Python code to bytecode which 
supposedly makes it quite a bit faster. 

You are right application speed is an issue. I know because my parents 
complain about slow startup of the document archive. But that  will be taken 
care of once we let Gnumed run in the background and connect to it from 
commercial progs via XML-RPC which should kind of work already.
>
Sebastian
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org] -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
My OS: Suse Linux. Geek by Nature, Linux by Choice

Unterstützen Sie die Entwicklung von freier Software durch Ihren
        Internet - Einkauf unter der Adresse:
http://profiseller.de/shop1/index.php3?ps_id=P1658133




reply via email to

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