When using OpenEMR in a large scale and there is a case that in a current day
more than 300+ appointments occurs the flow board up time is slow.
From testing the flow board algorithem at appointments.inc.php lines 167-302
can process about 8-15 patients per second and it takes 16-20 seconds for the page to load
Yup, just tested it , it is slow too
Hi,
Thanks for reporting on that.
Any thoughts on this @epsdky ?
(I am hoping that just a couple database keys/indexes will be needed)
-brady
The delay maybe loading 300+ records on the client side is slowing things down and that we need to paginate the number shown?
Couple things and replies from others here (some technical issues by one and got an email from another):
In the slow down, there seem to be several possibilities:
- The sql query just needs strategic id index/keys to support it (I hope this is the case) (testing would need 300 or so separate appt; ideally with 300 or so different patients)
- The function becomes inefficient if every single appt is part of a completely “separate” recurrent appt (testing would need 300 or so separate recurrent appt; ideally with 300 or so different patients)
- Client side gets bloated with that many entries (perhaps test by just hard coding function to only return 30 of the 300 appt)
- And possibly other stuff
Here are messages I have received regarding this:
the flow board is not slow due to the SQL I ran it in an SQL optimizer (EVERSQL which is not free but has a nice demo) and the improvement did not speed the performance
(so above seems to argue against item 1 above)
I set up 300 appointments (recurring everyday) for a patient with start date three months before current date. Took at most 2 seconds for the Flow Board to load on Xubuntu 64 on a 3 Ghz quad core machine.
(so above seems to argue against item 3 above)
-brady
@eyal ,
Also another possibility here is that you have a “bad” entry in your openemr_postcalendar_events data that is causing this. To this end, do you have another instance with this many patients that is also observing this problem?
-brady
regarding "I set up 300 appointments (recurring everyday) for a patient "
it is interesting I will check it but I think that everyday calculation is faster then marking specific days
maybe the slow down is not when there is 300 appointments for a single patient
we felt the major slow down when we have 300 patients with 1-2 appointments for the current day
Hello eyal,
The purpose of setting up 300 appointments for one patient was to verify that processing that many appointments at once would not take a significant amount of time.
To get the current day appointment date for a recurring series all the dates up to the current date have to be calculated.
Is the main calendar slow at loading the 300 appointments?
Is this a new installation? Was there a time when flow board was loading without delay with 300 appointments?
I am still trying to figure out the slow down
it seems that the problem is not related to the size of the patient_data nor the post_calendar_events table
since I created a procedure to create 6000 patients and random 1500 appointments
and it takes the flow board 3-4 second to load
but in another installation where I have 800 patients and 1200 appointments it takes 16 seconds
In the same environment
hi @eyal ,
Sounds like you may have a bad entry in post_calendar_events. To pinpoint it, could iterate (ie. try half, if good, try other half, if bad, try half of that and so on) until find the bad entry. Then post it here (if not sensitive data), so we can figure out if a bug created it.
thanks,
-brady
It is not that and it is really strange .
I took the data form the patient_data and from openemr_postcalendar_events
and put it in a new db (same server) and it takes 4 second to loads where in the origin db it takes 16 seconds
I guess I have no choice but to transfer table by table until I will figure out what is the origin of the problem