Tuning
This section covers areas that affect the performance of the system.
Tomcat
The memory available to Tomcat affects the amount of caching the OpenVPMS web application can use to improve response times.
The amount of memory currently used can be monitored via the Memory tab of Administration - System - Diagnostics. If Use is near 100% this indicates that the memory available to Tomcat should be increased.
The closer it gets to 100% use, the more cache shedding occurs. This can result in reduced response times.
Caching
OpenVPMS caches objects such as appointments, tasks, and lookups to improve performance. If these caches are too small, the database will have to be queried more often, reducing response times.
Caches can be monitored via Administration - System - Caches.
Note that if too much memory is allocated to caches, this can cause cache shedding, reducing response times.
MySQL
The main factor affecting MySQL performance is the memory allocated to the innodb_buffer_pool_size. This should be set as large as possible.
For a discussion on sizing the innodb_buffer_pool_size, see this Stack Overflow answer to the question 'How large should be innodb_buffer_pool_size'.
Hardware Selection
As always, the general advice is to buy the fastest you can afford. Adding more memory will improve performance provided that MySQL is configured with large buffers.
Till Balances and Bank Deposits
OpenVPMS adds all payments and refunds to a Till Balance for the Till assocated with the payment or refund. A Till Balance accumulates payments and refunds until it is cleared as part of the Till Balancing process.
Cleared Till Balances are added to a Bank Deposit, which accumulates them until it is deposited.
Even if a practice doesn't use OpenVPMS for accounting, these processes still need to be performed on a regular basis to stop individual Till Balances and Bank Deposits from growing too large. Large Till Balances in particular will affect response times when saving payments and refunds.
Medical Records Retrieval
The standard system can perform slowly when retrieving medical records for a patient with a long history. The apparent performance can be improved by limiting the number of visits retrieved for each query of the medical history. The standard system retrieves the complete medical history and then pages it out 20 visits at a time.
One can change this behaviour by limiting the number of visits on each query. If this is set to a number less than 20, then each 'page' of the medical history will display just that number of visits, and as you page through the history, a new query will be issued to get the next block of visits.
To limit the number of visits retrieved on each query to say 5, create a file called QueryFactory.properties containing one record as follows:
act.patientClinicalEvent org.openvpms.web.workspace.patient.history.PatientHistoryQuery,maxResults=5
This file needs to be placed in the folder <TOMCAT_HOME>/webapps/openvpms/WEB_INF/classes