I’ve always heard that the calendar should not be scheduled too far in advance because it puts a load on the server every time the calendar is opened. But what objective values are involved?
Would a schedule of 30 providers pre-booked for 6 months be expected to overload a generic google cloud install? How many could you book for 12 months without seeing any degradation in performance?
Thanks!
I’m interested as well to know if anyone has benchmarking on this.
I know that a repeated calendar event is stored as a single database record in the database for ALL the repeated events for that entry and then everything is calculated and populated inside of a loop in the getEvents function. It’s a very intensive function and I’m not sure why the data storage was implemented this way as I can see it as a huge problem for any kind of larger clinic. It also makes dealing with it at the API level a pain in the neck.
Our original calendar issue is still there but now we’re taking a different approach.
We saw that the OpenEMR instance is on one server and the database is on another, so all database queries, specifically loading the calendar appointments, have to pass over a network connection. When the patient list was small the delay was acceptable but as it grew it slowed things down a lot. We’re moving the database to the same server as the OpenEMR and hoping this fixes the delay.
Does this situation relate to your setup, @Mercy_Udele ?
I wish to make a quick note here concerning performance.
I spent many hours benchmarking and evaluating the project back around v6. I implemented a general fix concerning session locking and concurrency by us not opening a session in write mode by default where one then needs to set a flag if a session write is expected. This greatly increased overall performance.
Perhaps another look is needed.