[Gnumed-devel] Re: Gnumed-devel Digest, Vol 3, Issue 40

[sjtan]

> 
> Date: Wed, 26 Feb 2003 00:42:45 +0100 (CET)
> From: Hilmar Berger <address@hidden>
> To: Gnumed-Devel <address@hidden>
> Subject: Re: [Gnumed-devel] Where to start with gnumed
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> MIME-Version: 1.0
> Precedence: list
> Reply-To: address@hidden
> Message: 5
> 
> 
> 
> On Tue, 25 Feb 2003, Horst Herb wrote:
> 
> > Oh. DId I confuse everybody? Sorry.
> > What I meant to say is
> > 1.) we want to separate business logic from GUI code.
> > 2.) GUI code accesses business logic *always* at the highest possible / most
> > abstract level = level of a "service"  via XML-RPC
> What is the expected performance tradeoff when using XML-RPC vs. direct
> backend access ? After all , XML-RPC means
> GUI->XML-Layer->Socket->XML-Layer->Business-objects->Backend, that is at
> least 3 levels more while accessing the backend.
> 
> Hilmar
> 
the performance tradeoff is significant enough to worry about high 
granularity updates, e.g. field by field transactions, I think.
On the other hand, row by row transactions seemed reasonable,  

>From using tes_rpc_client.py and server2.py for profiling,  the client
forks off n processes and calls the rpc server r times to make an
arbitrary update to the enum_confidentiality_level.description field.

Results:
1 call is about 1-1.2 second, 10 forked calls about 1.5 seconds, 
20 forks doing 1 rpc call about 1.6 seconds, 10 forks repeating rpc
calls 2 times about 1.6 seconds , 2 processes , calling 10 times about 4
seconds, 1 process  with rpc calls 20  times about 8 seconds.  So there
is an overhead of about > 0.5 seconds for a call. 

Performance might not be an issue if the granularity is right:
field by field calls could still be done, if a client side outbound
queue was implemented, that hands off work to a queue of worker
processes to call the rpc server. The UI could just put in the queue and
return , and the queue could make good use of idle time to do updating.
There is already implementation of a thread-safe queue in pythoon when I
checked out
the library.

Might be fun to implement a test version to see if this would work.


> *******************************************