[Top][All Lists]
[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