Stress testing WASP using the EchoServerTest program
The simple echo server plugin that we developed in the earlier tutorial was easy to test using telnet as it simply echoed all data back to the client. The plugin which used simple message framing was less easy to test using telnet as you first needed to enter the correct bytes to specify a message length as an
int in network byte order.
Neither plugin was easy to stress test using telnet as you’d need lots of monkeys and lots of machines to simulate lots of users.
The Server Framework ships with an example client that allows you to create thousands of concurrent connections and control how they send data to a server. This is an easy way to build a test system for your server as all of the complexity of managing and controlling the connections is done for you and you simply have to adjust the messages that are generated and how the response validation is done. The default message that is built is an network byte order integer length prefixed message and so this program can be used to stress test WASP with either of the two example plugins that we’ve developed so far.
You can download the EchoServerTest program from here.
If you run EchoServerTest with no command line parameters you’ll get some help, something like this:
As a simple proof of concept test you can run up WASP using the echo server dll that we developed in the previous tutorial and then run the test program with the following parameters:
EchoServerTest -server localhost -port 5050 -connections 10 -messages 100 -messageRate 100 -sendAfterRecv
This will create 10 connections and send a total of 100 messages on each connection. Messages will be sent every 100ms and the 100ms timer will start when the response from the previous message has arrived.
You can use WASP’s performance counters to see what’s going on internally and you can adjust the number of connections and the message flow to simulate heavier loads. Note that you should be aware that there’s a limit to the number of concurrent outbound connections that you can make and that this is controlled by the MaxUserPort registry setting, see here for details of how to adjust this value, and if you find that you can’t create more than around 4000 connections then it’s most likely that MaxUserPort is still set to its default value.
The test we just ran creates all of the connections at once. This isn’t an especially realistic situation for most servers. You can adjust how EchoServerTest creates connections by using the connectionBatchSize and connectionBatchDelay parameters. For example, you might want to create 10,000 connections you might want to batch the connections into batches of 100 and have a 100ms delay between each batch. This still causes an awful lot of concurrent connections to be made but it’s slightly more realistic.
EchoServerTest -server localhost -port 5050 -connections 10000 -connectionBatchSize 100 -connectionBatchDelay 100 -messages 100 -messageRate 100 -sendAfterRecv
Likewise, a message rate of 10ms is pretty hardcore, but you can adjust your message rate to suit the likely usage patterns that you’re expecting.
To debug the simple message framing example DLL you could run the test with a single connection.
EchoServerTest -server localhost -port 5050 -connections 1 -messages 10
You can then debug the DLLs in the same way that we debugged the simple echo server.