Using the Service Tester
This Article provides a quick introduction to the Remoting Service Tester, a utility provided with both editions of the Remoting SDK (.NET and Delphi).
The Service Tester allows you to easily stress-test your Remoting SDK servers in high-load scenarios to see, for example, how various communication channels affect your servers' performance and your network's load. You can also generate test reports, save and reuse test scenarios, or embed the test into your QA process.
Running the Service Tester
You can start the Service Tester directly from within the IDE (Visual Studio or Delphi) by opening the
Remoting SDK|Service Tester menu, or you can launch it from the Start Menu.
After starting the Service Tester, you will be presented with a view selection window:
Note: for Visual Studio, there's another option. Selecting the
File|Add Item menu item adds a new
.roTest file to the project. When first opening (double-click in Solution Explorer), this launches the Wizard; for subsequent openings, it just launches the Service Tester with the test.
The Service Tester provides a
Create a new Test wizard that guides you through the steps of creating a new test. For the sake of this article we'll guide you through the process "the hard way", in order to help you better understand how things work. Once you become familiar with these steps, you can use the wizard for convenience.
The Service Tester uses predefined "Connections" to talk to your server. As you might recall from building your Remoting SDK applications, these connections consist of a Channel and a Message component.
To define a new connection, click the "
Server Connections" button in the toolbar, or press
Alt+C. This will present you with the
Server Connections dialog shown below:
Add button to create a new connection. Once the new Connection appears in the list, you can rename it, or choose a Message and Channel class in the grid. Let's rename this connection to
Local MegaDemo. Since we're going to test the MegaDemo Server application on our local machine, select the BinMessage and WinInetHttpClientChannel:
As you can see, most of the channels that you know are available for use (including the new Super Channels).
Once you have selected a Channel and a Message, you will see their properties appear on the right-hand side of the dialog.
For now, we'll leave all the properties intact, except TargetURL, which we'll change to point to http://localhost:8099/bin, the url for our MegaDemo.
At this time, it's probably a good idea to start the MegaDemo Server and activate its HTTP and TCP options. Once the MegaServer is running, you can click "Test" to see if the connection works. If all is working fine, you should see a MessageBox displaying "Library NewLibrary retrieved successfully".
If you see an error message instead, make sure that the server is actually running and is activated, and double-check the properties of your channel and message.
Ok to close the Server Connections dialog. You'll notice that the "Local MegaDemo" connection already is selected in the toolbar:
Setting up the Test
Now that everything is set, we can start communicating with our server. First, press the
Load RODL button in the toolbar, or press
Alt+L. This will cause the Service Tester to connect to the Server, retrieve the RODL file and compile the interface for it. You should see the details if in the Message pane at the bottom of the Service Tester:
Once this process is completed successfully, the Service Tester will activate the
Settings tab and automatically open the
Service Name combo box. Select
NewService, which is the only service defined by the Mega Demo, then Open the
Operation combo box, and select
Parameters grid below will automatically populate with the parameters of the Sum method (two integers called A and B, in this case). You can fill in the rest of the test values:
Once you're ready to run your test, click
Run Once. The Service Tester will dispatch the call to the server where the Sum method will be executed and then display the result value returned from the server:
Now that we've seen our call run successfully, it's time to stress test our server a bit, to see how it will cope with a high load of requests. Above the Parameters grid, you will find several edit boxes and check boxes that allow you to tweak the stress test. First, you can specify how many
threads you want to run simultaneously against the server. Let's put a 10 here. Next, you can select how many requests each of these threads should execute. Because the Sum operation is very fast, and we're testing against the local machine, let's pick a high number here and specify 1000 requests to be executed.
When you click
Run Test or press
Alt+R, the Service Tester will launch 10 background threads, and each thread will run 1000 consecutive calls to the server's Sum method. The Service Tester will also activate the
Test Status page, which will show you a live update of the test in progress, including the percentage of completed requests for each thread, and several graphs that illustrate the test through-put:
Once the test is completed, you will also get a complete text report on the Report sub-page.
In addition to simple types such as integers and strings, Service Tester also allows you to test service methods that expect or return more complex types, such as Structs, Arrays or Binaries.
To see how this works, let's go back to the
Settings tab and select the
EchoPerson operation. You'll see that the Parameters grid is filled with the new parameters that match the definition of EchoPerson, and that these are both of type "TPerson".
If you select the
aPerson parameter, you will see an Object Inspector type grid appear on the right-hand side, where you can edit the individual properties of the TPerson parameter:
In a similar way, after executing your request by clicking
Run Once or running a full test run, you can inspect the properties of the resulting
anotherPerson Out parameter.
On the same line, specific editors are available for arrays (i.e. if you select
TestStringArray) or binary types (i.e. if you select
Last but not least, let's highlight some additional features of the Service Tester.
First of all, you can save any Test settings that you have created as
.roTest files, for later reuse. This allows you to create a collection of tests for your server that can be integrated, for instance, to build an extensive test suite to integrate into your QA cycle and regression testing.
Also, you can save the result of any specific test as
.roTestResult and later review it by simply double-clicking on the file in explorer. This allows you to compare new tests against results from previous test runs - e.g. to detect newly introduced bottlenecks or confirm performance improvements.
If you're testing Data Abstract server applications with the Service Tester, the Data Grid tab at the bottom will allow you to inspect the Data Abstract datasets that are contained in the Binary types received.