soapUI

Performance and scalabilty of Jade web services can be tested by using the freely available soapUI tool. The use of this tool will be briefly demonstrated in this section. Version 3.0 of soapUI is used in this example.

Before we start, we should do the following.

1. Disable logging at the web server.

   You do this in IIS by using the MMC snap‑in. For details, see "Debugging", later in this document.

2. Minimize logging by jadehttp.

   If you turned tracing on in jadehttp, turn this off. For configuration options, see "Debugging", later in this document.

3. Turn off logging by the web service application. For configuration options, see "Debugging", later in this document.

4. Change your web service provider applications to be web‑enabled non‑GUI applications. If you use the GUI version, your performance will be degraded, as the web monitor status window is continually updated.

We will use ErewhonInvestmentsViewSchema in the Erewhon example system to demonstrate the use of soapUI.

1. From the Application Browser, select the WebServiceOverHttpApp application.

2. On the Web Options sheet of the Define Application dialog, change the number of application copies to 5.

3. Generate the WSDL.

4. Run the application.

   You should have five copies of the application running. Now bring up soapUI, which will display the window shown in the following image.

   

5. Select New soapUI project from the File menu, which will display the following dialog.

   

6. Specify the project name of ErewhonWebServiceTest.

7. Enter the WSDL path of the WSDL that was extracted previously.

8. Check the Create TestSuite check box.

9. Click OK.

The dialog shown in the following image is then displayed.

To keep this example simple, we create a test only for the four operations selected above. Unselect all other operations and then click OK.

When the request for a name for the test suite is displayed, click OK.

A window that looks like the example in the following image is then displayed. (You may need to expand your project to see this.)

We will need to enter some data for the getAgent and getClient methods. The following image is an example of the getAgent operation.

To do this, double‑click on the getAgent entry under Test Steps and then specify Hank Williams between the <web:agentName> and the </web:agentName> tags. Similarly, specify Brian Olsen for the getClient request.

We are now ready to run the test.

Click the green arrow icon at the left of the getAgent window. This will call the web service and return a SOAP message in the pane at the right, as shown in the following image.

You can also set up assertions for the call. In this example, set up five assertions as follows.

• Not SOAP fault

• SOAP Response

• Schema Compliance (WSDL compliance)

• Response SLA – set to 200 ms

• Response contains Hank Williams

The resulting assertions from this call are shown in the following image.

The response time was greater than 200 ms (286ms), hence the Response SLA assertion failed.

See the https://www.soapui.org online reference for documentation about assertions.

You can also run the tests multiple times.

Double‑clicking on the LoadTest1 item in the left pane will bring up the load test window at the right.

All of the items that we selected earlier are available for load testing.

There are several options to the test; for example, the number of threads, limit, strategy, and so on.

We are going to run the simple tests with a test delay of five ms, five threads, and running for one minute. Running this produces the following result.

The results show that we are getting transactions per second (that is, tps) of around 140. Note that in the getAgent case, there are three errors recorded and the bottom pane shows the reason. In this instance, all three errors relate to one of the assertions we added to the getAgent operation exceeding the required response time of 200ms. Putting in a longer delay will eliminate these errors but the transaction per second will then be fewer.

Scripts can be written to perform any initialization before the test is run (Setup Script) and to perform any finalization when the test is complete (TearDown Script). These tests can also be run without the user interface (UI). for more details, see the soapUI documentation.

The discussion in this section relates to measuring performance when providing a web service. If you are now consuming an external web service and want to measure performance as a Jade consumer, currently you will have to write your own test framework. If, however, you want to test just the performance of the web service, you can obviously use the soapUI tool by the process mentioned in this section.