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 flowsRegistration (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 visitNew 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 conditionRecord 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 side50th, 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.