The Bank Bought 1,000 RPA Robots. Its System Could Run 500.

Sona Hakobyan

Author

Sona Hakobyan

Sona Hakobyan is a Senior Copywriter at PFLB. She writes and edits content for websites, blogs, and internal platforms. Sona participates in cross-functional content planning and production. Her experience includes work on international content teams and B2B communications.

Senior Copywriter

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

Why an RPA platform needs performance testing at all

Robotic process automation is popular in banking for good reasons: document automation across financial products, fund transfers, customer verification and requests, data processing and checks. The vendor's promise is a digital workforce that runs 24/7, does not make mistakes and leaves a complete audit trail.

What that promise does not cover is how many robots your particular installation can actually run at once - and that is a property of your servers, your processes and your database, not of the software licence.

The bank wanted to expand its digital workforce and add functions. Before spending, it needed four answers: the maximum number of digital workers and processes the current configuration supports, how maximum productivity relates to server count, where the bottlenecks are, and which situations could bring the system down.

Why their own load testing could not answer this

The client had run load testing with their own resources and shared the results. They were unusable, for two structural reasons:

• The data was already out of date. Processes update regularly, and connecting new regional banks and processes changes the load profile - which can critically affect performance. Results are valid at the moment they are generated and decay from there.
• Indicators depend on the complexity of the processes being run. A process that creates and consumes queue elements stored in a database puts a far heavier load on application servers and the database than a supporting process that runs autonomously. Without a specific, representative load, the numbers mean nothing.

The finding that paid for the engagement

The bank had prepaid for 1,000 digital workers. Testing established the system's maximum capacity at 500 - and that at around 400 simultaneously active robots the load hit 100% and the system became unresponsive.

The lesson generalises beyond this bank: check your system's capacity before you buy the software, not after. A vendor's statement that your infrastructure will carry twice its actual maximum is not a measurement.

The engagement also had to answer *how* to scale - by increasing the capability of existing servers, or by scaling the architecture and deploying additional instances of the system. Those are different budgets and different timelines, and choosing between them without measurement is guesswork.

How it was tested

The production estate - one database server, 14 application servers, a load balancer and 700 robots - was exercised from five servers including load generators, with an emulator of the virtual workers performing tasks in place of the 700 digital workers.

The Blue Prism estate under test: application servers behind a load balancer, with the database alongside.

Results

• The system reached 100% load using almost the entire network capability - 9 of 10 Gbps - while a significant amount of other hardware sat unused. The constraint was not where the capacity was.
• Optimal configurations were established for different numbers of digital workers, plus recommendations for optimising the robots' own scripts.
• Hardware utilisation grew exponentially as more digital workers executed processes, so widening the network was not the answer - it would not have bought meaningful performance.
• Horizontal rescaling was identified as the way to grow, which is a different budget and a different architecture from buying bigger servers.
• The client added two further test stages after the project ended, and came back to PFLB with a second engagement on their own RPA system.

Questions this engagement answers

Can you performance test an RPA platform?

Yes, and it is a different exercise from testing an application: the load is generated by robots executing processes, so the test has to emulate the workforce, not user sessions.

Why not trust the licence count as a capacity number?

Because capacity is a property of the installation. Here the licensed number was 1,000 and the measured ceiling was 500, with degradation starting around 400.

Why do in-house RPA load tests go stale so quickly?

Because the load profile changes whenever processes are updated or new units are connected, and results depend heavily on which processes run - a mix of queue-heavy and autonomous processes produce entirely different loads.

Should capacity be tested before purchase?

This case is the argument for it. The gap between what was bought and what could run was 500 digital workers.