/performance-test

Primary LanguageScalaMIT LicenseMIT

Bahmni Performance Test

Design

Local Execution

Simulations can be run locally using Gradle. ./gradlew gatlingRun

Note: By default the simulation would run for Standard traffic. Please set LOAD_SIMULATION_TYPE env variable to High or Peak to simulate other traffic conditions and to dev to run with dynamic load conditions

Pre-requisites

  • Ensure at-least 50 patients are active in OPD
  • Clone the repository and navigate to root directory

IDE Execution export LOAD_SIMULATION_TYPE='Standard' && ./gradlew gatlingRun
High export LOAD_SIMULATION_TYPE='High' && ./gradlew gatlingRun
Peak export LOAD_SIMULATION_TYPE='Peak' && ./gradlew gatlingRun
dev export LOAD_SIMULATION_TYPE=dev ACTIVE_USERS=40 DURATION=10 UNITS=minutes && ./gradlew gatlingRun

AWS EC2 Execution

  • Get the ec2access.pem key from the infra admin
  • use the following command to login ssh -i "ec2access.pem" ubuntu@***********.ap-south-1.compute.amazonaws.com
  • Copy the scripts 📁 into the EC2 machine
  • Run this to start the test nohup bash ./startPerformanceTest.sh dev 40 30 minutes & in the scripts folder
  • To view execution progress tail -f nohup.out
  • To download report scp -i "ec2access.pem" -r ubuntu@***********.ap-south-1.compute.amazonaws.com:/home/ubuntu/Bahmni/scripts/performance-test/build/reports/gatling/* ./
  • To stop the execution kill -9 {JAVA_PID}

Stack

  • JDK 11
  • Scala 2.13
  • Gatling - Async Scala-Akka-Netty based -
  • Gradle Wrapper is already packaged, so you don't need to install Gradle (a JDK > 11 must be installed and $JAVA_HOME configured)
  • Minimal build.gradle leveraging Gradle wrapper and io.gatling.gradle plugin

Folder layout

📁 api

  • All HTTP requests responsible to make API calls to OMRS

📁 configurations

  • Possibility : Base object to represent possible variants of various User flows
  • Protocol : http protocol for running simulations
  • TrafficConfiguration : Contains 4 configurable load configurations such as Standard, High , Peak and dev
  • Feeders : csv data Feeders

📁 registries

  • Domain object registry that represents various functions performed by the user

📁 scenarios

  • Patient count will be calculated based on pace for each user and total duration

  • workload will be created for each user based on patient count

  • Closed System for simulating constant traffic of concurrent users

// Simulate 10 concurrent users traffic for 5 minutes with initial ramp of 30 seconds
rampConcurrentUsers(0).to(10).during(30 seconds),
constantConcurrentUsers(10).during(5 minutes)

📁 simulations

  • Current suit supports Bhamni Clinic simulation
  • Following closed system concurrent user configurations are defined in TrafficConfiguration
Load Type Concurrent Users Duration Initial Ramp Duration
STANDARD 40 1 hour 60 seconds
HIGH 50 1 hour 60 seconds
PEAK 70 1 hour 60 seconds
dev env variable env variable 10% of Duration

To get an idea how this behaves, have a look at this visual representation of a capacity load test:

Workflow

  • Trigger is set as Manual
  • The Run Performance Test trigger could be utilised to generate performance test report based CUSTOM_SIMULATION
  • The workflow performs the following steps :
    • Starting the EC2 Instance
    • Building the project
    • Running performance test in the EC2 instance based on the LOAD_SIMULATION_TYPE or CUSTOM_SIMULATION
    • To start the custom simulation provide the following as inputs
      • Number of concurrent users to test - Example: 50,70,100
      • Duration of test - Example: 5,10,24
      • Units for duration - Hours or Minutes
      • Valid reportname (optional) - Example: bahmniclinic-20230330090426833
      • Enter number of patients to be created (optional) - Example: 50,100 (These patients will be created and same will be replaced in registrations.csv)
    • By default the startup script which runs before the test closes all the exisiting active patients visits and create 60% of Number of concurrent users as new patients followed by starting the visit for them
    • Follow the steps in AWS EC2 Execution to view the progress and download the report

Note

  • Stop Performance Test EC2 instance this workflow can be used to stop the EC2 instance
  • Execution in GH Machine this workflow can be used to run the test in Github provided machine which is not recommanded due to hardware restrictions
  • Manually executing scrape.py helps to fetch values from gatling reports, according to HEADERS set in .env file, and convert it into a CSV file.
  • WIP - To convert CSV files into an interactive dashboard for easier comparison of reports and deducing the best executions based on patient encounter count, no: of concurrent users and so on.