Do the servers and client PCs all have sufficient performance? What about all the underlying software products such as the operating systems and databases – have they been correctly configured? And your SAP BPC systems themselves, have they been written in the best way and fully tested with representative data volumes?

If there is an issue in any of these layers it may only become apparent when your SAP BPC system is placed under load. For example, at month-end, when users are simultaneously loading data, running reports, consolidations and more, will users find response times acceptable, or will system performance deteriorate to an unacceptable level?

If you suspect your SAP BPC system is not performing as well as it could, how will you monitor its performance and identify the bottleneck(s) without waiting for the next period of high load? How will you measure the impact – positive or negative – of applying any configuration changes to the system?

To get a definitive answer on these questions and many others you need to run an SAP BPC stress test.

Many people will tell you that it is not possible to perform realistic stress or performance testing on an SAP BPC system, or that it is not important. But I can assure you that it is possible and that it is important to know in advance how your system will perform under any given load.

There are a variety of methods that can be used to perform SAP stress testing. It’s quick and easy to have a number of users manually start processes at the same time, but it’s not the most scientific approach, and it’s difficult to test realistically when the size of the user community runs into hundreds or thousands.

It is preferable to use a specialist stress testing tool; as in this way a variety of test scenarios can be configured, monitored, and repeated consistently for large numbers of simulated users.

Our approach to an SAP BPC Stress Test

Opal Wave’s approach is to treat every stress test as a distinct project, with a dedicated, experienced project team following an approach that encompasses several stages including gathering customers’ requirements before designing specific tests, performing them, and analysing the results.

Most stress tests take place as part of an overall system development project. The stress test is often scheduled to take place during system development, after the build and testing stages, and before go-live. There are many reasons for this: Ideally we want the tests to run in an environment that is identical to the one that users will experience, so in order to do that we need to run the tests in the production environment (or a realistic copy of it), using a realistic data set, and with the complete BPC system with finalised functionality.

What an SAP stress testing project looks like

Typically a stress test project will start with a workshop to define the objectives. For example, the main objective may be to understand system performance under periods of highest load, or to test the impact of changing the underlying hardware or SAP BPC functionality.

To analyse system performance under periods of highest load, we examine what tasks are being performed at those times; these are often a combination of users logging on, loading data, running logic packages, and running reports. From this analysis we can build a series of test scenarios that replicate that load.

Now that we understand what tests to run, we identify and customise the various SAP BPC application components. This is primarily to ensure that tests are repeatable and consistent, so for example for each user running the consolidation package will be assigned a group of entities that is unique to them and is consistent.

During each test we monitor key performance indicators and our programmed software monitors the performance of each virtual user session, i.e. how long it takes each user to complete each task as the system load increases.

During the period of the tests themselves, which is usually in the range of a few days to a few weeks, we may make configuration changes to the system then repeat the testing to assess the impact of those changes. It is not uncommon for each test to be run several times as different configurations are evaluated to determine which is optimal.

After completion of the test we document the test results and present our findings.

Examples of SAP Stress Test Projects

We recently performed a stress test for a customer migrating their SAP BPC system from v7.5 MS to 10.1 on the SAP HANA platform, including a series of enhancements.

This was of particular value as they have several hundred users located around the world, and relatively high data volumes (over 2,000,000,000 records). One of the acceptance criteria for the project was that system performance must be improved.

As a result of the stress test we were able to demonstrate the level of performance the system would deliver, and assure them of the benefits of their investment in the new system. Without a stress test it would not have been possible to prove the system met their performance criteria before go-live, at which point it would be too late to rectify any issues.

Another customer was particularly concerned about the ability of their system to handle a large number of concurrent report requests from their community of several hundred users.

We successfully demonstrated their system could handle over 160,000 report refreshes per hour, which comfortably exceeded their projected future maximum demand on the system.

This level of throughput was only achievable after several configuration and application changes were made, which would have been very difficult to identify and retest without a stress test.