Difference between revisions of "CDR Performance"

From OpenEMR Project Wiki
Line 18: Line 18:


*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.
:*Proposed mysql indexes ('''It has been confirmed that these indexes drastically improve performance of the Patient Summary page and other CDR related page''')
:*Proposed mysql indexes '''('''It has been confirmed that these indexes drastically improve performance of the Patient Summary page and other CDR related page)
::*'pid' and 'type' indexes on the 'lists' table
::*'pid' and 'type' indexes on the 'lists' table
::*'pid' index in the 'form_vitals' table
::*'pid' index in the 'form_vitals' table
Line 28: Line 28:
::*'pid' index in the 'transactions' table
::*'pid' index in the 'transactions' table
::*'patient_id' index in the 'extended_log' table (stores disclosures)
::*'patient_id' index in the 'extended_log' table (stores disclosures)
::*'patient_id' index in the 'prescriptions' table
::*'patient_id' index in the 'prescriptions' table'''
:*If add indexes need to also include in the upgrade script and can take advantage of the [http://dev.mysql.com/doc/refman/5.0/en/show-index.html SHOW INDEX] and [http://dev.mysql.com/doc/refman/5.0/en/create-index.html CREATE INDEX] mysql commands to do this in a safe fashion.
:*If add indexes need to also include in the upgrade script and can take advantage of the [http://dev.mysql.com/doc/refman/5.0/en/show-index.html SHOW INDEX] and [http://dev.mysql.com/doc/refman/5.0/en/create-index.html CREATE INDEX] mysql commands to do this in a safe fashion.



Revision as of 21:17, 10 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.
  • Proposed mysql indexes (It has been confirmed that these indexes drastically improve performance of the Patient Summary page and other CDR related page)
  • 'pid' and 'type' indexes on the 'lists' table
  • 'pid' index in the 'form_vitals' table
  • 'pid' index in the 'forms' table
  • 'pid' index in the 'form_encounter' table (only in the upgrade script)
  • 'patient_id' index in the 'immunizations' table
  • 'patient_id' index in the 'procedure_order' table
  • 'pid' index in the 'pnotes' table
  • 'pid' index in the 'transactions' table
  • 'patient_id' index in the 'extended_log' table (stores disclosures)
  • 'patient_id' index in the 'prescriptions' table
  • If add indexes need to also include in the upgrade script and can take advantage of the SHOW INDEX and CREATE INDEX mysql commands to do this in a safe fashion.


  • Potentially related to coding. Awaiting further testing/debugging to locate performance bottlenecks before taking any action here.
  • Remove php time limit for scripts:
  • openemr/interface/patient_file/reminder/patient_reminders.php
  • Place set_time_limit(0); php command at top of script under the require_once stuff
  • Also add a javascript processing animation to the scripts that will take awhile.


  • Debug and reporting from users/developers/vendors with large databases.
  • Can either do this via tools(such as Firebug, 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 (when reporting, very useful to know the size of the following mysql tables: patient_data, form_encounter, form_vitals, lists).