Calendar load limits

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!

  • Harley

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.

I have issues with my calendar on version 5.0.1(4) on Windows server. The calendar takes about 3 while minutes to dispkay when you click it.

Not sure how to fix this.

From my experience, the load time was almost the same even without many appointments compared to 6 thousand appointments spread over a month.

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 ?

  • HT
1 Like

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.

My Openemr instance and database are on one server.

I am on Openemr V 5.0.1 (4) with Xampp on windows server 2016 (production )

and windows 11 (test server).

We have nit been able to fix this issue.

I wonder if upgrading will help solve the problem.

That means my v5 may be part of my problem.

Been worrying about upgrading to V7 safely without losing my modifications and patient data/;lab configurations.

Upgrading may be inevitable.