Scalable Load testing of web Services on Cloud using Soap UI

Scalability is the capability of a system, to handle a growing amount of load, or its potential to be enlarged in order to accommodate that growth.

Before going to the production an application developer needs to do performance/load testing of any web application/ web services. Always we want cost effective solution for this purpose.
For this is motive you must have load testing framework in your toolbox.

MY Tool kit- In my  tool kit I have open source Soap-UI 5.2.1, elastic search, mysql, jenkins 2.0 and groovy to do load testing for Soap/Rest service on AWS cloud.

Why load testing is requires ?

Perform a load testing for SOAP and Rest services for following reason:

1. Get the average response time and test per second of web service under certain load.
2. Ensure the maximum capacity (number of requests per second) of the web server based on the current hardware infrastructure.
3. Get the CPU, Memory, Disk IO and Network usage for web server under certain load.
4. Exposes potential bottlenecks in your system and generate a load test result report for analysis.

Achieve this by using Soap-UI oppen source addition-

SoapUI  is great tool for the functional as well as load testing. It generate the request and response using data contract provided through WSDL or WADL. Soap-UI comes with the capability of groovy script implicitly, it helps to manipulate the request, response as well as to get and save the test data to/from external sources.

Soap UI has user friendly GUI which help a lot to create test suite, test cases and test step. SoapUI also support the property transfer test steps which helps to parse the response from previous request and set the properties at project, test suite, test case level. Properties are key value pair which can be accessed inside the request using expression language e.g ${#Project#PropertyName}. More details about SoapUI.

According to me groovy script is the heart of SoapUI. We can use groovy test step to parse the response and apply some use case logic and set the properties for next request or store the responses in external sources which can be used for further processing.

At the time of load testing I was interested in numbers like avg response time (avg) and test per seconds (TPS) and number of requests depending on load test strategy. SoapUI community edition provides Basic CSV file reporting. We integrated elastic search for reporting with Soap UI for load test results. For more about performance matrix.

The distributed SoapUI load test results is dumped into the Elastic Search and the reports are visualized using the Kibana web user interface.

When we through load on system we need to get the some metrics like CPU, Memory, Disk IO, Network utilization. We achieve it bu using PerfMon a Jmeter Server Agent and custom TCP client for it. The tcp perfmon client also inserting the result into elastic search. It will be very helpful to analyze the load test stats with performance metrics.

loadtest

The above mention setup work well from single instance but load testing need to scale on multiple instance to generate more load on server. In that case the current setup works as master node having Elastic search, mysql, PerfMon Tcp client, SoapUI load test runner and Jenkins for managing master/slave node. The Jenkins master will distribute the SoapUI load test runner job on SSH Client slave machines in a network. The slave node run the SoapUILoadTestRunner Job and publish the load test result to elastic search hosted on the master node. The scalability is achieved through adding n-numbers of slave node on the Cloud. These slave nodes are ubuntu based EC2 intances.

loadtestslave

This is cost effective solution for load testing using open source SoapUI against the paying huge license cost of SoapUI Pro and LoadUI Pro which help us to get more or less same result.

 

2 thoughts on “Scalable Load testing of web Services on Cloud using Soap UI

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.