Load testing for medical corporation's automated system

One of our biggest clients is a clinic chain that has the key player position in the domestic medical market. The chain consists of ambulatory care clinics, medical test centers, family clinics, children’s clinics, health resorts and fitness centers. It employs around 100 doctors of medical sciences and more than 2 thousands physicians.

The entire customer infrastructure is based on an internal information system (MIS) that is aimed to automate medical bodies workflow.

  • medical e-cards management;
  • united medical body’s informational space;
  • quick medical documents and statistics retrieval;
  • automated bill creation.

The Performance Lab team was going to test the latter.

Got a project in mind?

There is no better place for a QA solution than Performance Lab.
Drop us a line to find out what our team can do for you.

Task

The customer planned to introduce a new architecture and needed to know, how many servers are required to sustain the maximal system load. We had the following goals before us:

01

Determining the system performance parameter for the current production load (determining target performance values for the planned user load of 3000 users);

02

Discovering the bottlenecks (determining the list of factors that limit the system performance).

Solution

The system is based on two layers of architecture: thick client (interface level and partly business-logic) and database & file server (data saving and management level).

The main load source are user activities that use RDP protocol on terminal servers with the thick MIS client exclusive third-party systems.

Load testing was performed on an anonymized production database copy. System load profiles have been based on customer’s expert evaluation data. We’ve emulated the load through the terminal sessions and developed load scripts to emulate the most important user operations. LoadRunner (RDP) was used to provide load, Perfon to monitor the process, jupyter (pandas/matplotlib) to analyze the results.

Results

We have found several important system limitations and internal element conflicts after the first testing iterations. After the system analysis we’ve developed recommendations how to solve the above problems. The customer had to solve them on their own, so that we could perform the testing again and solve the set task.

The hardware analysis has lead to the needed amount of the terminal servers that allow the system to sustain the maximum load level. The results allowed the customer to organize the servers and ensure continuous work of the IT infrastructure. We have had our first big project working with the RDP protocol that gave us a chance to broaden our knowledge in this area.

Download
brochures

More information about QA solutions we provide is available in our brochures

PL CSV SOLUTION

PL CSV SOLUTION

TEST AUTOMATION SERVICES

TEST AUTOMATION SERVICES

CASE STUDY: TOP 10 BANK AT

CASE STUDY: TOP 10 BANK AT

AGILE PERFORMANCE TESTING

AGILE PERFORMANCE TESTING

IVR LOAD TESTING SERVICES

IVR LOAD TESTING SERVICES

CASE STUDY TOP 10 BANK LT

CASE STUDY TOP 10 BANK LT

CASE STUDY RETAIL

CASE STUDY RETAIL

CASE STUDY GOVERNMENT

CASE STUDY GOVERNMENT

QA OUTSOURCING WHITEPAPER

QA OUTSOURCING WHITEPAPER

Latest posts from us

mobile-application-test
Mobile Application Test: How Does It Work?
regression-test
Top Regression Testing Tools
How Granularity Influences the Load Testing Results
How Granularity Influences the Load Testing Results with Grafana+lnfluxDB & LoadRunner Analysis
bug-reporting
How to Write a Comprehensive Bug Report
Guide-for-CRM-System-Testing
The Beginner’s Guide to CRM System Testing