Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

All the estimates projected are based on tests performed for 24 hours on single namespace/ single cluster concept with multiple concurrent users and a shared RDS for Bahmni Lite 1.0 release.

Clinic setup - 2 frontdesk users, 2 doctors (4 users)*

Smaller clinic setup - 1 frontdesk user, 1 doctor (2 users)*

Cost Estimation Sheet with Results

Comprehensive test results and calculation estimates can be viewed in this document: Bahmni Lite Setup and Cost Estimation

The below analysis explains the various design factors that were taken into consideration during the above performance test calculation process.

Lesser clinics cluster (approx 40 concurrent users)

t3.large instance is suggested for Bahmni lite implementation since the number of active pods may vary from “14 to 22” based on the requirement. t3.large supports upto 35 kubernetes pods and enables seamless deployments.

Hardware

Node (EC2: t3-large)

  • RAM 8GB

  • 2 vCPU

  • AWS LINUX x86_64

  • Max pods supported: 35

Database (AWS RDS service: db.t3.xlarge)

  • RAM 16GB,

  • 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)

  • 100GB Secondary storage

  • MySQL, max_connections = 1304

Report

https://bahmni.github.io/performance-test/longduration_report-20230130141239257_40users_24hrs_all_omods_afterhipfix/index.html

Pre Patient Records in DB - 75000

The given hardware supported 40 concurrent users during our test with acceptable performance. The clinical activities performed under the test were

Activities

Total performed

Single user performed

Patient Created

5760

720

Patient Search

8640

720

Patient Consultation

5760

288

Patient Document Upload

1440

720

Based on the above numbers, two default provisions to setup the cluster

  • suggested - If the expected patient demand forecast matches the tested numbers by more than 75%, consider this setup

  • maximum - If the expected patient demand forecast matches the tested numbers by less than 75%, consider this setup

4 users clinic setup (suggested)

  • 1 to 10 clinics

4 users clinic setup (maximum)

  • 1 to 12 clinics

2 users clinic setup (suggested)

  • 1 to 20 clinics

2 users clinic setup (maximum*)

  • 1 to 24 clinics

Cost Estimation

Comprehensive approximate estimates are found in this document

Bahmni Lite Setup and Cost Estimation

More clinics cluster (approx 70 concurrent users)

m5.xlarge instance is suggested for Bahmni lite implementation on this setup since both the CPU and RAM availability is twice than t3.large and supports upto 58 kubernetes pods.

Hardware

Node (EC2: m5-xlarge)

  • RAM 16GB

  • 4 vCPU

  • AWS LINUX x86_64

  • Max pods supported: 58

Database (AWS RDS service: db.t3.xlarge)

  • RAM 16GB,

  • 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)

  • 100GB Secondary storage

  • MySQL, max_connections = 1304

Report

https://bahmni.github.io/performance-test/longduration_report-20230213133118638_70users_24hours_AfterHIPfix_m5xlarge/index.html

Pre Patient Records in DB - 90000

The given hardware supported 70 concurrent users during our test with acceptable performance. The clinical activities performed under the test were

Activities

Total performed

Single user performed

Patient Created

10080

720

Patient Search

14400

720

Patient Consultation

10080

288

Patient Document Upload

2160

720

Based on the above numbers, two default provisions to setup the cluster

  • suggested - If the expected patient demand forecast matches the tested numbers by more than 75%, consider this setup

  • maximum - If the expected patient demand forecast matches the tested numbers by less than 75%, consider this setup

4 users clinic setup (suggested)

  • 13 to 17 clinics

4 users clinic setup (maximum)

  • 13 to 20 clinics

2 users clinic setup (suggested)

  • 25 to 35 clinics

2 users clinic setup (maximum*)

  • 25 to 40 clinics

*- The number of users assumed are based on the number of requests sent by a user on an average to the server and typical clinic setup observed from real time sources.

  • No labels