[Top][All Lists]

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

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

From: sjtan
Subject: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 19, Issue 10
Date: Sun, 06 Jun 2004 10:21:18 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113


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 

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 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.

reply via email to

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