[Top][All Lists]
[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.
- [Gnumed-devel] re: low performance, sjtan, 2004/06/06
- [Gnumed-devel] Re: low performance,
sjtan <=
- Re: [Gnumed-devel] Re: low performance, Horst Herb, 2004/06/06
- Re: [Gnumed-devel] Re: low performance, Ian Haywood, 2004/06/07
- Re: [Gnumed-devel] Re: low performance, Sebastian Hilbert, 2004/06/07
- Re: [Gnumed-devel] Re: low performance, Jim Busser, 2004/06/08
- Re: [Gnumed-devel] Re: low performance, Karsten Hilbert, 2004/06/08
- Re: [Gnumed-devel] Re: low performance, Karsten Hilbert, 2004/06/08
- Re: [Gnumed-devel] Re: low performance, Horst Herb, 2004/06/08
- Re: [Gnumed-devel] Re: low performance, Karsten Hilbert, 2004/06/14