How can I do a stress test in the XI?

1. Scenario :

1. You have developed a synchronous interface (webservice) in XI and want to benchmark the performance of the webservice by generating the required message load
2. Applied a new Service Pack and want to test the impact of the service pack on the performance time of services
3. Want to simulate the timeouts produced in your production landscape due to high call volume
4. Want to stress the Integration hub to see how the resources (threads/memory) are being handled by XI

2. Problem :

There are many ways for simulating message load to XI. Simplest of all is to have have a super users group who could call the XI webservice repeatedly for a given period of time. But this approach will not generate the desired pattern of load (simultaneous load to XI). The other approach would be to automate the testing process by writing custom applications for making concurrent XI calls using thread polling. The main problem with this approach is we need to build a very generic testing tool that could test any webservice, this could take up a lot of development time and resources.

3. Solution :

The best way to achieve a true concurrent heavy message load is to use automated testing suite like LoadRunner from MERCURY . LoadRunner provides a means to generate load based on number of concurrent users with behavioral patterns. These users can be configured to make the webservice calls all at once or based on user pattern or time interval or continued execution for a fixed interval of time. LoadRunner consists of the following components

1. Quality Center : Acts a data store for storing all the load scripts, can also be used for scheduling scripts

2. VUGen (Virtual User Generator) : Is used for generating load scripts, can used to for recording user actions webservice/websites

3. Controller : This is the component that is used for running the scripts, scenarios can be created where the number of virtual users can be defined. Controller forks the calls to the various load generators.

4. Load Generators : primarily responsible for executing the scripts. Each Generator has a maximum limit of 200 concurrent users.

Note : This blog is not intended to provide in dept information on Mercury LoadRunner but is more concentrated on how to use it for testing webservices.

4. Example :

Step 1: Scan the wsdl and generate the script using VUGen. Please look at the technical article "Load Testing Web Services in an ESA Landscape, Part I". This is a very good article that provides detailed steps on generating the scripts. Scripts can either be saved into Quality center or to the local disk.

Step 2: Launch Controller, create a new scenario and select the script to run from Quality Center or from local disk.

Step 3: In the controller choose the number of virtual users(2) , load generator(3) and start the scenario.

Step 4: The run tab shows real time statistics like number of passed transactions, average response time, number of virtual users running.

5. Conclusion

Mercury LoadRunner testing suite is a very handy when trying to simulate realistic volume. It can be used in many ways in a large scale ESA implementation, especially the testing scripts come really handy during SP upgrades and for getting a bench mark on the performance of the services.

6. How to get it :

Mercury has now partnered with SAP and is now providing LoadRunner under a combined Licensing from SAP.

7. More Information :

SAP LoadRunner by Mercury

Mercury LoadRunner

8. Useful Articles on using LoadRunner :

Load Testing Web Services in an ESA Landscape, Part I