PFLB

Load Testing for Medical Corporation's Automated System

One of our biggest clients is a network of medical treatment and prevention facilities that holds the key player position in the domestic medical market. The network consists of diagnostic centers, clinic hospitals, medical test centers, family and children’s clinics, health resorts, and wellness centers. It employs approximately 100 doctors of medical sciences and more than 2000 physicians.

The entire customer infrastructure is based on an internal information system (MIS) to automate the workflow:

  • patients’ electronic records management;
  • unified informational space;
  • quick medical documents and statistics retrieval;
  • automated bill creation.

The PFLB team was hired to test the latter.

Want to learn more about our
performance testing services?

Find out what’s included and how to start working with us

Clutch badge orig
European Testing awards 2019 badge
Techreviewer 2022 badge orig
CTA performance testing

Task

The customer had planned to introduce new architecture and needed to know the number of servers required to sustain the maximal system load. We had the following goals:

01

Determining the system performance parameters 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 was user activities that employ the 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 were based on the customer’s expert evaluation data. We emulated the load through the terminal sessions and developed load scripts to mimic the most important user operations. LoadRunner (RDP) was used to provide load, Perfon to monitor the process, and Jupyter (pandas/matplotlib) to analyze the results.

Results

We found several important system limitations and internal element conflicts after the first testing iterations. After the system analysis, we developed recommendations on ways to solve those problems. The customer was required to solve them on their own, so that we could perform the testing again and solve the set task.

The hardware analysis led to the required number of the terminal servers to allow the system to sustain the maximum load level. The results allowed the customer to organize the servers and ensure continuous function of the IT infrastructure. This was our first big project working with the RDP protocol that gave us a chance to broaden our knowledge in this area.