Re: [Gnumed-devel] Re: low performance

[Sebastian Hilbert]

On Monday 07 June 2004 10:37, Ian Haywood wrote:
> On Mon, 07 Jun 2004 11:07:54 +1000
>
> sjtan <address@hidden> wrote:
> > Message: 2 Date: Sat, 5 Jun 2004 19:04:33 -0400 From: Ian Haywood
> >
> > Maybe we should experiment with a backend xml-rpc server now , to see
> > how much a local business object server
> > and local sql communication  will speed up remote communications, as
> > Karsten as mentioned.
>
> To be honest I remain sceptical: XML_RPC is going to add a lot of overhead
> of its own and the server still has to make all these queries, even if they
> are over a local socket.
>
> > > start typing notes etc. while stuff is loading. I'm not sure about the
> > > best way to implement this yet.
> >
> > would be nice if we had non-blocking writes and socket select with db-api
> > !
>
> We can emulate this using threads easily (as we already wrap the DB-API
> with gmPG.py)
>
> >  - change to request /  event notify / receive   style of business
> > object invocation, instead of rpc style, as is currently.
> >           - within the business object, there would be a request queue
> > and a consumer / dbapi calling thread that
> > services the queue, and places the results in a synchronized dictionary,
> > then issue  events on a event dispatcher
>
> IMHO this is the way to go. (although I apprecipate its very different from
> what we have) To digress a little, the problem is for Karsten and Sebastian
> gnumed is something that works Right Now, and will soon be able to do more
> stuff, integrated with other clinical packages, which is why Karsten is
> (understandably) relunctant to go and refactor the design. However in AU
> this is not the case: gnumed needs to have a lot more functionality before
> it becomes usable in any real way, which is why issues of slowness and GUI
> complexity are more real: I fear the way we are going the client will be
> too bloated and messy to use.

>
> > 3. unsynchronise business object request, response, and gui update using
> > event driven coding style in the client. Use client-side business object
> > proxies to do the waiting and response notification.
>
> I would envision a middleware that's a bit more like PROLOG: a set of
> rules, each with 4 elements 1 - the event that fires them (either GUI,
> backend via NOTIFY/LISTEN or internal like "new_patient") 2 - the
> GUI-specific function which grabs data from the appropriate widgets 3 - the
> SQL query, run in the background
>       4 - the GUI-specific function which unpacks the data and loads it into
> widgets (which MUST be in the foreground thread)
I admit I understand very little of what you guys are talking about but that's 
ok. To clarify our situation. *Right now* we need excactly two parts of 
Gnumed. First one being the lab module which is nearing completion regarding 
what we need. Second one is the document Archive.
For reasons discussed many times my Archive/lab module is not very fast when 
being cold started. This means running the plugin standalone, being called 
from our proprietary application is close to unusable speedwise.
That's why we want these two plugins running in Gnumed. Gnumed will remain 
running in the background at all times. The commercial app will bring 
Gnumed/plugins to the front via XML-RPC. This should speed things up. 

This shouldn't hinder any refactoring/development work.(?) 

Take a look at the work on the manual in the Wiki (started yesterday) to read 
more about those two modules.
>
> Ian

-- 
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