gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: low performance


From: sjtan
Subject: [Gnumed-devel] Re: low performance
Date: Mon, 07 Jun 2004 11:07:54 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Message: 2 Date: Sat, 5 Jun 2004 19:04:33 -0400 From: Ian Haywood <address@hidden> Subject: Re: [Gnumed-devel] low Performance
On Sat, Jun 05, 2004 at 06:18:21PM +0200,

A number of optimisations we know about: business object caching, preloading the waiting list,
etc. most of which can be done post-0.1 IMHO


However, there is one thing I think we should consider now (because it only
gets harder from now on:
for a lot of things, we have a search function which returns a list of id
numbers, then we instantiate business objects from each ID. This is were it gets needlessly slow: we have a separate SQL query for each returned item. Instead the original search query should be a "select * from", not "select pk from", and the search function then populates the business
objects with this data.

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.


Ideally, all DB communication should be done by a background thread, so the user can 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 !

2 possible ways might be ( using the principle that operations on shared resources must use some synchronizing primitive (locks, queues, semaphores) for atomicity) :

1.
- 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 to notify requestors to pick up the results from a synchronized dictionary. (synchronized meaning the dictionary is protected by a lock when get / put; I'm not certain python dictionaries are thread-safe i.e. no other thread can do a __putitem__ when servicing another thread doing a __putitem__ or __getitem__ )

2.
- start a client function in a separate thread, which call business object function but then business objects would have to be re-entrant and maybe need BoundedSemaphores to wait on limited connections ( start with a BoundedSemaphore of size 1, if connection pooling is broken currently; this semaphore might need to be shared across all types of business objects). Also call wxCallAfter in those client functions to call gui update functions.





Also, currently gnumed establishes a separate TCP connection for every commit transaction,
a obvious and simple point for optimisation.

I thought there was connection pooling.


Some other options to try out , might be:
- using dedicated email instead of an xml-rpc server, as a cheap application messaging middleware. Too hacky? - using web servers as an application messaging server (more control of what messages are sent than xml-rpc). - partial replicated postgresql servers on each client, client side business objects, and a replication manager on each client and server.



summarising what's been said on this thread, specific solutions might be:

1. xml-rpc server; localises multiple sql calls to the same machine or server LAN , returns aggegrated results as (larger) business value objects,

2. connection pooling ; fix it and use it again, to save on connection establishment time (tcp 3-way handshake)

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.


2 is the easiest to do. 3 would require a minor re-write of what's been done now, and not doing it now, means re-writing all the business object synchronous calls later, when more of the gui is connected.








reply via email to

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