Performance Baseline & capacity test plan [MVP for PATH]

 

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.

 

The Bahmni documentation is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)