OpenMRS Load Testing Strategy

Development Quality Assurance
,
15

Hey everyone,

Update: We’re now running tests with demo patient data!

Why the change?

Systems like Bahmni generated empty patients with zero observations for each test run. But for accurate load testing, we need a rich, realistic data environment.

How Did You Do It?

So, how did we make this happen? We considered three options:

  1. Create patients within the scenario.
  2. Create patients using the API before running tests.
  3. Leverage demo data generation.

Option 3 was the winner! It helps generate patients with realistic data. Here’s the scoop:

  1. Spun up an instance and set the value of referencedemodata.createDemoPatientsOnNextStartup to 300 to start. This is a time-consuming task.
  2. Wrote a script to export patient UUIDs to a CSV file.
  3. Used the CSV file to feed patient IDs into the simulation.
  4. Preserved the database as a dump file.

When running tests on GitHub actions, the dump file loads first, making patient data generation a one-time task.

What’s the Current Status?

Curious about the current status? Here’s the lowdown:

  • The simulation runs with 200 concurrent users (100 doctors + 100 clerks).

  • Tests currently run for around 2 minutes. I’ll extend this period soon.

  • Tests are running on standard GitHub hosted runners with 4 CPUs, 16GB RAM, and 14GB SSD. This is less than the O3 minimum hardware requirements, which is a good sign.

  • New addition - Doctor persona: Each doctor performs the following

    1. Login
    2. Open Home Page
    3. Open Patient Chart Page
    4. Start Visit
    5. Review Vitals and Biometrics
    6. Review Medications
    7. Review Orders
    8. Review Allergies
    9. Review Conditions
    10. Review Attachments
    11. End Visit

    The feeder runs chronologically and repeats patients once the list is finished.

How can I help?

  • Check out a recent report and give me feedback! Click me!!! :cat:
  • Review the source code and let me know your thoughts. @ibacher, thanks for your comments!
  • If you’re involved in performance improvements, use these reports as a reference. You can identify slow-performing endpoints in the “stats” table. These tests run daily, and you can download the latest reports here: GitHub actions.

What’s next?

So, what’s next? I’ll post an update on our decision regarding concurrent users soon. Other tasks are:

  • Add more activities to the doctor persona, especially data entry tasks.
  • Introduce load scenarios and make them configurable.
  • Introduce CI build failures based on assertions for performance metrics.
  • Publish the latest report as a link to ensure easy access. Ideally, host the report on a static server such as GitHub Pages.

Thanks!

cc: @grace @dkayiwa @raff @janflowers @burke

1 Like