Bahmni Connect Performance Baseline

This page is currently in progress and the numbers are not currently ready for public consumption. We are in process of testing Bahmni Connect under various loads and configurations, and are also executing some spikes to improve performance even further. Please watch this page for final numbers. Thanks!


Introduction

To ensure the connect app works fine in various network conditions and load, there are performance tests done to come up with representative numbers. These numbers will help in capacity planning for the app and understanding the right Software/Hardware requirements before setting up the app.


Device/Configuration used for performance

Device/
Config
Chrome (Win)Samsung TabBahmni Server (AWS)
versionWin 7 (32-bit)-0.86
Android-4.2.2-
RAM*4 GB1 GB8 GB
CPU*2.40Ghz1.2Ghz Dual Core2.40GHz 2 cores
Storage-3.5 GB (8GB)32 GB
IP/Hostname
-

Hosted on AWS


Initial Sync Time Vs Network Bandwidth (Chrome/Tab)

Device

Network Bandwidth

#Patient

# Events

Total Time

(Min)

Chrome

2G (450kb/s-150kb/s)

30

9685

48

Chrome

Wifi (1.9Mb/s - 1.2Mb/s)

30

9685

30

Samsung Tab

Wifi (1.5Mb/s - 1.9Mb/s)

30

9685

95

Samsung Tab

2G (450kb/s-150kb/s)

30

9685

120


Device Performance Post Sync: Chrome/Tab

Device

Flow

#Encounters

Total Time (Secs)


Chrome

Create Patient -> Save

3500

1.78

Clinical -> Patient Listing

10.11

Patient Listing -> Patient Dashboard

7.5

*Patient Dashboard -> Observation

2


Samsung Tab

Create Patient -> Save

3500

5

Clinical -> Patient Listing

8

Patient Listing -> Patient Dashboard

17

*Patient Dashboard -> Observation

3


Observations

1. Post sync, there's a lag of 4-5 secs on both the Chrome and Tab. Thus, a blank screen appears for every navigation that is performed on the devices."

2. If Sync fails for 16000+ events, the refresh doesn't start the sync again for remaining events, which is expected. Appears some storage issue with indexed DB in chrome"

3. The size of the DB grows along with the no. of events respectively. Refer the chart

4. If there are 5 devices running initial sync in parallel, the CPU utilization of mysql on bahmni server was recorded more than 75%"

5. The overall time for Sync depends on #Events, Network bandwidth, OS Configuration. For instance, 16000+ events took more than 3.5+ hours"


Recommendations

  1. Bahmni Connect worked fine for smaller set of patients i.e. Patients: 30 and Encounters: 3500, thus, need to define the sync strategy accordingly to choose the smaller set of patients and encounters.
  2. To configure multiple devices in parallel, choose 2-3 devices at a time to configure as this will reduce the sync time on each device. Don't plan more than 5 devices at a time as it might make the server very slow and chances are likely high to get sync failures.
  3. At any point if the sync fails, the sync can be restarted by logging again to the app. Sync will start again from the last failed event and thus, will keep the existing data in tact.


Known Issues

  1. Diagnosis goes undefined if the Nutritional value is left empty
  2. Performance Bug - If the initial sync fails for more than 16k events, the sync doesn't resume post refresh. Investigation has been started to resolve this

  3. Chrome: Adding Connect app extension and opening the app fails with "Offline Data not setup", if the chrome session was already active. 
    WorkAround: Close the chrome App and open the app again.
  4. If user opens another tab/s in the same chrome instance, then initial sync stops. 
    WorkAround: Open another chrome instance, instead of another tab in the same chrome instance