gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: patient search widget timings -more comment


From: richard terry
Subject: [Gnumed-devel] Re: patient search widget timings -more comment
Date: Fri, 28 Mar 2003 08:52:02 +1100

BTW when we load in the patient stuff it should come up with the summary 
screen as default. This loads all of the following
==============================================
-social history
-family history
-active past history
-outstandings (pathology etc)
-habits (drugs/smokingetc)
-risk factors
-active medications tab
-scratch pad
==============================================

Also as soon as we have this patient wigit thing working, can we set up 
something like a comma delimited text import so I can import the names and 
address of all my patients into the database to try it out. Then we can start 
working on something simple like the social history.

Regards

Richard

On Friday 28 March 2003 8:40 am, you wrote:
> I tried the same thing in my vb client.
>
> It gets its data via my 100MB network from Win4lin to the e-smith linux
> server running on an old Pentium 350. It takes a little over 1 second to
> retrieve an entire patient record  including the summary screen.
>
> Regards
>
> Richard
>
> On Friday 28 March 2003 2:28 am, you wrote:
> > I have done a few timings on the search widget.
> >
> > When I type "becker" I am expecting 207 patients to be
> > identified as matching. It takes
> >
> > - 1.77 seconds to download the 207 matching IDs
> > - 70.5 seconds to download more patient data for display in
> >   the patient selection list (id, last name, first name, dob)
> >
> > When I type "hilbert" I am expecting 2 patients:
> >
> > - 1.82 seconds to download IDs
> > - 4.5 seconds to download more data
> >
> > When I type "hilbert,k" I expect 1 patient:
> > - 1.66 seconds ID retrieval
> > - 1 second until the patient is in the widget (no list)
> >
> > Conclusion:
> >
> > This is not where we want to be but I would say it is fairly
> > reasonable given the test environment below. I will time the
> > same queries with the commercial EMR from which I borrowed the
> > patient records once I get back to work. For the time being
> > the code can go in I'd say.
> >
> > Regards,
> > Karsten
> >
> > test environment
> > ----------------
> > server:
> >  - Pentium 133 MHz
> >  - 40 MB RAM
> >  - 300 MB Swap
> >  - (quite) old SCSI drive
> >  - CPU load around 95%
> >
> > PostgreSQL:
> >  - 7.1
> >  - shared buffers set to 512
> >  - accessed over 10 MBit/s LAN
> >  - 22 000 patients in database
> >  - fetch will return lists, not dicts
> >  - patient.id indexed
> >  - data download queries running with WHERE id = ..
> >  - queries running against view v_basic_person
> >
> > load:
> >  - concurrently importing more patients (80 000 to go)
> >  - no other significant server load




reply via email to

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