[Gnumed-devel] Re: Gnumed-devel Digest, Vol 19, Issue 10

[sjtan]

>  
>
> ---------------------------
>
> Message: 5
> Date: Sat, 5 Jun 2004 17:42:45 +0200
> From: Hilmar Berger <address@hidden>
> Subject: [Gnumed-devel] low Performance
>
>  
>
> then it might be more efficient to move more logic from business objects to the 
> backend.
or  xml-rpc servers, that run the logic local to the sql backend , 
making multiple sql calls locally ?

> One could as well try to fetch a larger but more fuzzy junk of patient related data in some backend method and do the selection of needed data in the business objects. 
>  
? like a sql view which is not conceptually obvious, but lets one return 
multiple parts of patient data in groups of attributes of one row.
? or a patient  structure that can be a xml-rpc return value.



> It is also quite obvious that caching or even preloading patient data (from 
> waiting room list) could boost performance. Right now changing a patient 
> removes all data of the former one.
>
>  
? Patient data more like file objects , and the server calls more like 
ftp calls

> Maybe some points are really post-0.1 issues, on the other hand we shouldn't 
> implement algorithms that are known to be lowering perfomance.
Pre-loading caches synchronously might be such an algorithm ( I noticed 
gmContacts took 20 seconds to load , and I know  who's responsible 
there  ; )
- there's an interesting experiment; re-write the pre-loaded stuff using 
a multi-threaded approach, and see if hherb.com access time can be dropped.
- another reason this might be slow, is there is more than one select , 
as there is more than one preload occuring, and the selects are being called
on one connection in a single threaded fashion; off loading the the 
multiple select to one thread can make use of user fiddling time when he is
fiddling with the gui after it starts up before doing useful work , at 
the expense of possible inconsistency ( e.g. user looks up occupations, 
and finds
none, looks up again 10 seconds later, and finds the list filled).
- Off loading to multiple threads , might be even better , but would 
require multiple sql connections , possibly. ( for n select calls, 
instead of n x network latency  it would be more like 1 and a bit x , ) 
- the cost would be using up say 10 connections per user , and the 
server only having 100 connections allowed, maxing users to 10.

- sorry, just a learner reinforcing by expression   ( BTW, this is off 
topic, but does anyone know if debian is a lot better than say mandrake 
for installing
a *integrated*  freeswan(ipsec) + kernel  setup ? )
- is gmPG setup for multiple connection pooling , and how to make use of it?

> Telling a new user that he could try the public db but should not wonder if it 
> is awfully slow could lead to rather unpleasant first encounters with gnumed.
>  
>
> Hilmar
>