1. Scope

Develop performance test automation to validate total number of clinics that can be supported on a given infrastructure configuration.

• Baseline Hardware:

  • Bahmni Lite: RAM 16GB, 4 vCPU and 100GB Secondary storage

  • Database: RAM 8GB, 2 vCPU and 100GB Secondary storage

• The automation would simulate Varying Traffic Load conditions

  • Standard Traffic Load: 40-50 Active users

  • High Traffic Load: 50-70 Active users

  • Peak Traffic Load: 70-110 Active users

• No existing data would be considered (It will start from Fresh DB)

• Support 2-3 user flows such as registration, and consultation

• Performance Baselining would be performed for BahmniLite (Clinic implementation) on AWS environment

2. Introduction

The purpose of this document is to provide an outline for the performance test where baselining & capacity of the system will be covered.

• Entry & exit criteria

• Load tool Selection & approach

• Baseline and Capacity test approach

• Test execution activities

• Risk Factors

3. Entry criteria

• Identification of critical flows

  • Registration (New and Existing Patients)

  • Doctor consultation

  • Patient documents upload

  • [Stretch scope] Bahmni Report

• Performance test types finalization

  • Baseline (expected response time) to support clinical operation on a given hardware configuration for varying traffic load

• Load generator tool

  • Gatling

• Server performance monitoring

  • Prometheus (Metrics)

  • Grafana (Dashboard)

• Data setup

  • Users setup (2 front-desk, 2 doctors - per clinic)

  • [Draft] Data growth pattern for a clinic Click Here

4. Exit criteria

The testing activity will be completed when:

• Gatling Performance test reports are generated and published

• Report summarizing number of clinics (by user categories) that can be supported for standard load (standard baseline)
  

5. Load Tool Selection & approach

Gatling will be used as the load generation tool as the team has earlier experience of working with it. Gatling is good at creating and emulating a large number of users compared to Jmeter without adding more hardware. Comparatively Gatling is less resource intensive, hence it makes a good choice compared to Jmeter.

The key challenge with Gatling is the version upgrade e.g. minor version upgrade results into breaking changes.

6. Baseline and Capacity test approach

⭕️ Simulations

Below test simulations would be executed to depict various user flows. It won’t have any pre-existing data except for the users preconfigured.

• Front-desk / Reception - Patient registration and visit

  • New Patient: Registration and start OPD visit

  • Existing Patient: Search using Name/ID and start an OPD visit

• Doctor’s Consultation

  • Access patient profile and documents

  • Average Patient health condition

    • Record 10 Observations

    • Prescribe 3 Medication

    • Order 1-2 lab test

Expected data presence for a clinic

• For baseline, a clinic will start only with preset users only. There will be no patient data.

• For subsequent tests to mimic growth of the clinic, we will retain test data.

⭕️ Baselining

We need to baseline expected response profile for various API’s during user flows (get, query, update, list etc) for varying traffic load conditions (standard, high and peak)

⭕️ Capacity

The peak traffic load simulation would give us maximum load (clinical active users) the system on a given hardware configuration can take (acceptable UX performance) before its starts to either fail OR degrade UX.

⭕️ Key observations

• Client side

  • 50th, 75th, 80th, 90th, 95th percentile response time of each API call

  • Any error received

• Server Side

  • CPU usage

  • Memory usage

  • Disk utilization

7. Test execution activities

The following tasks need to be performed to complete the performance test.

• Create performance test environment

• Install Prometheus & Grafana on the server

• Enable server log for debugging

• Scripting of user flows in Gatling

• Sequence the user profiling

• Execute the tests

• Analysis of each execution

• Performance Report generation and publish
  

8. Risk Factors

Following might affect the execution of the test plan/timelines.

• Scala is relatively new for the team. So we need to refer to the documentation & existing Gatling code.

• Need a spike on best way to import or set up prerequisite data. This is needed to expedite the test relaunch.