[Top][All Lists]

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

Re: [Gnumed-devel] emr browser speedup

From: Syan Tan
Subject: Re: [Gnumed-devel] emr browser speedup
Date: Mon, 29 May 2006 08:05:12 +0800

if the requests and replies were asynchronous , then you could have a worker queue, and a receive queue,

and nothing would block on longer queries ( hopefully , as long as there were a pool of connections server side).

alternatively, have 2 worker queues, low and and high priority. that would be similiar to having 2 request threads

per client.

On Mon May 29 5:28 , Syan Tan sent:

the queue idea works as long no query takes a long time. Once a query which takes a long time

reaches the head of the queue, the rest of the queue becomes blocked, and the

urgent query that needs to jump to the head will still need to wait.

On Sun May 28 16:33 , Ian Haywood sent:

Karsten Hilbert wrote:
> Hi Syan,
> I am reviewing your work on this. Thanks for your input.

> Anyways, what I'm trying to say, the EMR browser data
> retrieval code should perhaps rather operate on simple dicts
> which the middleware delivers from the database.
I agree completely. The middleware needs a serious diet ;-)
It's job should be fetching and maintaining caches of dicts in a generic
way, the actual form of the dicts should be determined by backend views,

IMHO we could have a central registry of queries and a single cache, which is
a big dictionary where the keys are a tuple (query_name, arg1, arg2, ...)

I'd be wary of multiple threads, as these imply multiple DB connections.
Remember each connection means the backend has to fire up a postgres process
on the server, as well as TCP overhead, then these backends start competing for disk.
By the time you've finished, it may not be faster. (of course,
I'm happy for this to be benchmarked and so proved wrong ;-)

Better IMHO a "query queue" feeding a *single* background worker thread, queries
which are "urgent" (ie. the user is waiting on the result) go to the
head of the queue, prefetches go to the back.
When the results are in, the worker thread then passed data to the GUI thread
via wxCallAfter ()

> Part of
> which (sub-encounter/sub-episode data) should probably be
> piped through Cheetah to get some nicely formatted HTML
> (template user selectable) to be displayed on the right hand
> pane.
Yep, sounds good.


Gnumed-devel mailing list


reply via email to

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