Difference between revisions of "CDR Performance"

From OpenEMR Project Wiki
Line 13: Line 13:


==Plan==
==Plan==
:Upgrade Jquery, since this should improve the ajax calls from the main patient screen, hopefully avoiding the CDR-unrelated ajax calls from being effected by the CDR-related ajax calls. Note this has already been done by yehster in the 'master' branch: http://github.com/openemr/openemr/commit/a23f3e34e5410f4cdd61f3304b9e0900a8c3e699
*Upgrade Jquery, since this should improve the ajax calls from the main patient screen, hopefully avoiding the CDR-unrelated ajax calls from being effected by the CDR-related ajax calls. Note this has already been done by yehster in the 'master' branch: http://github.com/openemr/openemr/commit/a23f3e34e5410f4cdd61f3304b9e0900a8c3e699
:*Awaiting feedback if this helps performace of the larger databases.
:*Awaiting feedback if this helps performace of the larger databases.


:Potentially related to mysql indexing since performance gets worse as the number of patients increases. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.
*Potentially related to mysql indexing since performance gets worse as the number of patients increases. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.


:Potentially related to coding. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.
*Potentially related to coding. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.


:Debug and reporting from users/developers/vendors with large databases.
*Debug and reporting from users/developers/vendors with large databases.
:*Can either do this via tools(such as XDEBUG, KcacheGrind, and/or monitoring sql query freq/time) or via observations and reporting of the following:
:*Can either do this via tools(such as XDEBUG, KcacheGrind, and/or monitoring sql query freq/time) or via observations and reporting of the following:
::*Going through adminstration->alerts and working through the rules one at a time.
::*Going through adminstration->alerts and working through the rules one at a time.

Revision as of 22:12, 9 October 2011

Several issues have been brought up in the forums, regarding performance of the CDR engine. Here are the forum threads:

Our experience with the new OpenEMR 4.1.0
OpenEMR 4.1 is very slow
Patient Reminders (4.1.0) fails on large db

Issues

Patient Summary page widgets related to CDR are slow
  • Notable, this gets slower as the number of patients in the database increases.
  • Also, the other non-CDR related widgets(with ajax calls) appear to be slowed down by the CDR related widgets(ajax calls).
CDR engine based reports are slow
  • So far, the Administration-Reminders reports has been reported to not work with a patient database size of 4500 users. Suspect this issue will also be encountered in other CDR engine based reports.

Plan

  • Awaiting feedback if this helps performace of the larger databases.
  • Potentially related to mysql indexing since performance gets worse as the number of patients increases. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.
  • Potentially related to coding. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.
  • Debug and reporting from users/developers/vendors with large databases.
  • Can either do this via tools(such as XDEBUG, KcacheGrind, and/or monitoring sql query freq/time) or via observations and reporting of the following:
  • Going through adminstration->alerts and working through the rules one at a time.
  • Set as Patient Reminder to test the Administration->Reminders page or the Patient Reminder widget on the Patient Summary page.
  • Set as Passive Reminders to test the Clinical Reminder widget on the Patient Summary page.
  • Testing all the reports in Reports->Clinical to see which ones are running fine and which ones aren't
  • Reporting the results in one of the above sourceforge threads or on this wiki page.