Our test environment setup is described below: (see Table 1)

A document-style Web Service has different payloads being passed on as SOAP message elements. These documents vary in size to measure the response time given by a Web Service invocation. Network congestion or the time spent in the communication pipeline distorts the Web Service's actual response time. To measure the true response time of a Web Service, the service is locally hosted, eliminating any network-related bottlenecks.

The Web Services are hosted on the JBoss application server that resides on a machine with the following setup: A Dell server PE 1600SC with an Intel 2.8GHz Xeon CPU and 1GB of RAM. The various performance parameters like response time, throughput, number of transactions passed/failed, and load size are measured against different payloads for RPC and document styles of Web Services and the results are shown on graphs.

Results
Load testing summary of a document/literal-style Web Service

Payload size: 10KB
Number of concurrent users: 25
Total test duration: 10 minutes (see Figure 2)

The graphs above depict the variation of the average response time of a document/literal-style Web Services at a constant payload size of 10KB. Note that the average response time is significantly nominal and the performance of the service remains stable over the given period of time.

Payload size: 100KB
Number of concurrent users: 50
Total test duration: 15 minutes (see Figure 3)

The same document-style Web Service when evaluated for a medium payload of 100KB performed the same as the graphs depict.

Payload size: 500KB
Number of concurrent users: 50
Total test duration: 15 minutes (see Figure 4)

When tested for a high payload of 500KB and 50 concurrent users, the document-style Web Services remain stable. The average response time remains significantly low at around 1.2 seconds. None of the transactions failed.

Load Testing Tools
There are commercial tools like Mercury's LoadRunner and Radview's Webload that are very efficient and detailed for load testing Web Services. There are various Open Source alternatives to LoadRunner that can serve our purpose of load testing to varying degrees. Some of the more popular tools include the soapUI 1.6 beta, the Grinder 3 beta, and OpenSTA. soapUI provides basic functionality to create test cases, execute them, create sample SOAP clients, etc. Grinder uses a highly detailed language called Jython to write the test scripts.

Conclusion
Software testing is a crucial phase of the SDLC and load testing is an integral part of any efficient testing scheme. This paper highlighted the importance of load testing with specific reference to Web Services. The design principles entailed attempted to bring about a proper plan for testing, the parameters to be looked for, and the expected results. The strategies contained in this paper can be implemented regardless of the platform on which the application is deployed and the tools used for testing.

References