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.
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:
Determining the system performance parameter for the current production load (determining target performance values for the planned user load of 3000 users);
Discovering the bottlenecks (determining the list of factors that limit the system performance).
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.
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.