gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] patient search widget timings


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

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]