At a glance
- Client: a network of medical treatment and prevention facilities holding the key player position in its domestic medical market - diagnostic centers, clinic hospitals, medical test centers, family and children's clinics, health resorts and wellness centers
- Scale of the staff on the system: approximately 100 doctors of medical sciences and more than 2,000 physicians
- The question asked: the customer had planned to introduce new architecture and needed to know how many servers were required to sustain the maximum system load
- Load target: determine target performance values for a planned user load of 3,000 users
- Architecture under test: two layers - a thick client carrying the interface and part of the business logic, and a database and file server
- How load was generated: through terminal sessions over RDP, against an anonymized copy of the production database, with profiles built from the customer's own expert evaluation data
- Toolchain: LoadRunner (RDP) for load, Perfon for monitoring, Jupyter (pandas/matplotlib) for analysis
- Outcome: the hardware analysis produced the required number of terminal servers to carry the maximum load level, which let the customer organize the servers and keep the IT infrastructure running continuously
A hospital network runs on one system, and it was about to be rebuilt
The customer's entire infrastructure is built on an internal medical information system (MIS) that automates the workflow: patients' electronic records management, a unified informational space, quick retrieval of medical documents and statistics, and automated bill creation. PFLB was hired to test the last of these.
That single sentence carries the stakes. When a hundred doctors of medical sciences and more than two thousand physicians work inside one system, the system is not a piece of software the business uses - it is the way the business happens. Records, statistics, documents and billing all sit behind the same client. The customer was planning new architecture underneath it, and the question in front of them was not "is it fast enough today" but "what do we have to buy for it to be fast enough tomorrow." Guessing that number wrong in either direction is expensive: too few servers and clinics stall at peak hours; too many and the network pays for idle hardware indefinitely.
So the goals were set as two, and only two:
1. Determine the system performance parameters for the current production load - that is, establish target performance values for the planned user load of 3,000 users. 2. Discover the bottlenecks - produce the list of factors that limit system performance.
How the load was built
The MIS is a two-layer system: a thick client that holds the interface level and part of the business logic, and a database and file server that handles data saving and management. There is no browser in this picture. The main load source was user activity running the RDP protocol on terminal servers with the thick MIS client, alongside exclusive third-party systems.
That shaped every decision about how to test it:
- Load testing was performed on an anonymized copy of the production database, so the data volumes and distributions matched reality rather than a synthetic fixture.
- System load profiles were built from the customer's expert evaluation data - the people who know what a clinic day actually looks like, rather than an assumed distribution.
- Load was emulated through the terminal sessions, and scripts were developed to mimic the most important user operations.
- LoadRunner (RDP) provided the load, Perfon monitored the process, and Jupyter with pandas and matplotlib was used to analyse the results.
This was PFLB's first large project working with the RDP protocol, and it broadened the team's knowledge in that area.
What the first iterations found
After the first testing iterations, several important system limitations and internal element conflicts came out. PFLB analysed the system, developed recommendations on how to resolve them, and handed them over - the customer was required to solve them on their own so that testing could then be repeated and the original task completed.
That sequence is worth stating plainly, because it is the shape most honest capacity testing engagements take: the first run rarely produces the answer. It produces the list of things standing between you and the answer. The number only becomes trustworthy on the second pass, after the limitations found in the first are gone.
Results
- Several important system limitations and internal element conflicts were identified and written up as recommendations.
- After the customer resolved them, testing was repeated, and the set task was completed.
- The hardware analysis produced the required number of terminal servers for the system to sustain its maximum load level.
- The results let the customer organize the servers and ensure continuous function of the IT infrastructure under the new architecture.
Questions this engagement answers
How do you find out how many servers a system needs?
By measuring the existing system under a load profile that matches the planned one, then reading the hardware requirement out of the measurement. Here the target was 3,000 users; the deliverable was the number of terminal servers needed to carry the maximum load. This is hardware sizing as an engineering result, not a vendor estimate.
How is the scope of a load testing project set?
Narrowly and in writing. This one had exactly two goals - target performance values for a 3,000-user load, and the list of factors limiting performance. Everything else about the MIS was out of scope. A scope that specific is what makes an engagement finishable, and it is a fair thing to ask any vendor for before signing.
Can you load test a thick client that users reach over RDP?
Yes. The load is emulated through terminal sessions rather than HTTP, scripts drive the most important user operations inside those sessions, and LoadRunner's RDP support generates the traffic. There is no browser to record, so the profile has to come from the way people actually work in the client.
Why test against a copy of the production database?
Because response time in a records-and-billing system is dominated by data volume and distribution. An anonymized production copy preserves both while removing patient identity - which is the only version of this test that is both realistic and safe to run.
Planning new architecture and need the server count before you buy?
The useful deliverable is not "the system is slow" - it is a hardware number you can put in a purchase order, measured against your real user load on a copy of your real data. If your users reach the system through a thick client over RDP, that is testable too; it just changes how the load is built.
