| Table of Contents |
|---|
...
| Expand | ||
|---|---|---|
| ||
|
Code repository
Archive Report Path - GH Pages
...
Test Execution Steps
Clone all the repositories.
Use the Wondershaper to set the network speeds only if needed.
Run the test data generator to create and upload new patients.
Copy the registrations.csv file from 📁 /output to 📁 /src/gatling/resources .
Start the test by providing the simulation type , number of users, and duration of the test.
To run the test against different environments update respective env properties in
📁 src/gatling/scala/configurations/protocols.scala and 📁 src/gatling/scala/api/constants.scala
To run the test in cloud use the trigger in GH actions.
...
By default, Openmrs comes with Open JVM memory management which is not optimal for applications with large memory footprints. So we moved to CMS(Concurrent Mark Sweep) which gave us a low GC pause time and higher throughput for minimal patient data. - BAH-2660.
We have configured the min, max heap size and parallel GC threads.
This change has reduced the max time taken by the POST API call to save encounters for 90 users test run from 4149 ms to 1551 ms.
More details about the baseline test reports can be found here
...
Saving the consultation page takes more time due to a groovy parse class function, By disabling the parse class function the response time for a single API call is reduced from 2.5s to 1s - BAH-2870.
The HIP health check module was pinging OpenMRS patients and visit API every 5 seconds causing the environment to go down due to Out-of-Memory Exception constantly whenever the patients count reaches 125k - BAH-2441, BAH-2783. (this was fixed). The fix for this issue has reduced the max time taken by the POST API call to save encounters for 70 users test run from 60s to 4s.
HIP and Crater atom feed were also pinging OpenMRS to query the event feeds causing high GC pauses which in turn spiking CPU utilization - BAH-2801, BAH-2912.
The update of GC strategy from CMS to G1GC has helped to control the CPU spike.
Without the HIP, Crater atomfeed and updated G1GC settings the 99th percentile has reduced to 1.5s.
More details about the JVM configurations, infra setup and long duration test runs can be read here: Bahmni Lite Performance Long Duration Simulation Baselining
...
Based on the long-duration test results and corresponding AWS utilization bills we have come up with a cost calculator. Link: Bahmni lite operational cost estimates (Projected)
Anyone can create a cloud cost estimation to set up Bahmni LITE by providing the no. of users, users-per-clinic, and operational hours.
...