Yes we thought of the following approaches:
- Refactor Queries
Most queries were already optimized, were able to bring down processing time from 5sec to less than 2sec for 3 queries. That did not improve the performance of queues.
- Use Yourkit trial version to profile the Java process; see which function is taking most time and causing CPU spikes.
Openmrs handles the creation of connection, so we could not play around with connection pooling and statement pooling configurations. But we discovered that ‘statement.executeQuery’ took the maximum amount of CPU time. Too many calls to this method at the same time caused the cpu to spike to 100% utilization and the application could not recover from it for sometime.
- Check if we are have binding issues like use of - bind twice or bind once etc.
- Checked data binding, it was already one way binding so nothing to improve there
- Tried infinite scrolling, Loading limited data first and on click of “Load more” more data will be loaded. But performance was the same
- Try UI side caching - we need live data on every click.
The final conclusion was to reduce the no. of concurrent calls to the patient search api, so we implemented that using debounce.