Calendar performance

We are in the process of analyzing and addressing the Calendar OpenEMR performance issue which was posted in this forum on and off.
If you have experienced a performance issue with the OpenEMR calendar, could please reply to this thread by explaining the scenario or query.
-ViSolve OpenEMR Support team

We found recurring appointments to be a major drag on performance since it requires repeated evaluation of all records with type=recurring. This was partially mitigated with two operational changes -

  1. For events that are repeating in principle but not so in practice
    Common examples would be annual physical, monthly follow-up etc. In practice it is extremely rare that a patient would keep showing up on every July 5th for annual physical for n years. It is better to have rules based reminders that do not affect performance of demographics screen.

  2. For rare instances when events are truly recurring, convert past events to normal events on a daily basis so the php routine goes through minimal iterations.

@visolveemr, It would be worthwhile to incorporate / extend tplaner’s when class and migrate to a true appointment class instead of current code. That approach is easier for all to understand, maintain and extend the calendar functions.

Hello All,
Finally we have loaded OpenEMR 5.0.2 with more than 100K records and ready to measure with some response time measurements.

  1. We have loaded over 100K records
  2. We are thinking of simulating 3-5 subscribers for calendar (scheduler) performance.
    Do you think the above scenario is a typical representation of OpenEMR deployment or should we tweak the number of subscribers and/or the number of patient records?
    Any input is greatly appreciated.
    -Visolve-001