One of our customer is planning to roll out new BI functionality to 2000 additional users. They were concerned whether their current BI infrastructure can support this kind of load. So they asked us to perform stress testing using BI Validator with the following two key objectives:

  1. Can their BI system reasonably support a concurrent user load of 200, 400, 600?
  2. What is the number of concurrent users where the performance of their BI System starts going downhill (breaking point)?

We installed BI Validator in their Virtual Machine (VM) and started off trying to simulate the stress tests but soon we found out that BI Validator was not reaching the expected concurrency limits. Upon further analysis, we found that there were two issues that were stopping BI Validator from simulating the expected concurrency:

  • Windows 7 Operating System was not allocating more than 25% CPU processing power to the BI Validator instance.
  • The processor of the virtual machine was dual core AMD and not quad core Intel with hyper threading.

As a result, the number of concurrent users (threads) were not ramping up fast enough to simulate the load.

The solution was to use multiple VMs to simulate the load and have multiple instances of BI Validator running in each of the VMs. Specifically, five instances of BI Validator were started concurrently in each of two VMs (total 10 instances of BI Validator). Each instance of BI Validator simulated a load of 100 concurrent users. As a result, the CPU usage in each of the VM hit 100% and the spike in the concurrent users applied a real load on the BI System. We immediately observed heavy BI and database activity with active sessions in both instances of the BI Server.

The screenshot above shows multiple instances of BI Validator running in the same machine while consuming more than 25 % CPU usage.

This exercise helped the customer understand bottle necks in their BI system. They were able to determine that :

  • Their Presentation Server and BI Server are capable of handling the concurrent user load.
  • Their database instance showed bottlenecks in database memory and caching size as user load started increasing beyond 300 concurrent users.