Stress Testing

Introduction to Stress Testing
Preparing for the Stress Test
Issuing Stress Test Commands
Viewing the Stress Test Report
Stress Testing Chats
Troubleshooting

Introduction to Stress Testing

Web Crossing has a built-in stress testing feature that provides an invaluable means for a sysop to test the capacity of and optimize a Web Crossing server.

The way it works is as shown in figure 1. A second (it may be unlicensed) Web Crossing server is used to send requests automatically to your main Web Crossing server. These requests take the form of multiple clients accessing the main Web Crossing server and pounding it with read and write requests. The testing server also generates a report you can use to evaluate the main server's performance and make necessary adjustments to optimize serving performance.

Figure 1 - Running a Web Crossing Stress Test

The actual stress test commands are issued by sending special URLs to the second Web Crossing server.

The second Web Crossing server can run on the same machine as the main server you are testing, or it can run anywhere on your LAN or over the Internet. To get the best, actual results of your Web Crossing server performance run the second Web Crossing on the same machine as your main server. This will avoid network delays in sending and processing requests.

Preparing for the Stress Test

A test folder in the top level of your main server is required for carrying out the read and write requests sent by the second server. In the example here, we have created a test folder called Test in the top-level folder. After the stress test is completed you may delete the folder.
You should note the sysop password for the main server - you will need this when sending the stress test command to the second server.
Install the second server. You can install the second server on your own personal computer, on the same machine as the main server (running under a different port number, in direct web service mode) or on any networked machine. The second server need not be licensed; a bronze server will do just fine.
Note the sysop password for the second server - you will need this information also when sending the stress test command to the second sever.

Once you have prepared, you are ready to issue a stress test command to the second server.

Issuing Stress Test Commands

A stress test command sent to the second server is a URL of the following form (URLs here are broken for clarity, and so they appear correctly on the page, but these should be all one line):

http://secondURL?200@sysop:pwdSecond@204- clients-duration-interval-viewsPerPost- http%3A//ipAddress/cgi-bin/webx%3F14%40 sysop%3ApwdMain%40/Test
Example:

http://www2.webxharbor.net/webx?200@sysop:tmppwd@204- 5-900-1-20- http%3A//202.219.13.82/cgi-bin/webx%3F14%40 sysop%3Asupersecret%40/Test

The various parts of this URL are:

http://secondURL - the full URL of your second Web Crossing server. In our example, we have our second Web Crossing server running at http://www2.webxharbor.net/webx.
?200@ - the URL code for running a stress test. When the second Web Crossing server sees this command it knows to interpret the rest of the URL as a command to issue stress test requests.
sysop:pwdSecond - sysop is the login name of the sysop and pwdSecond is the sysop password on the second server. In our example, we have set up the second server so that the sysop has the password "tmppwd".
@204- - this marks the beginning of a stress test command sequence.
clients - the number of clients (web browser accesses) that will be simulated. In our sample we have asked that 5 clients be run.
duration - the duration of the stress test, in seconds. In our example we have requested a 900 second (15 minute) test. This will give us a good, long snapshot of the performance of the main server.
interval - the amount of time, in seconds, between requests for each client. In our example we have specified "1", so there will be one request every second. To have more requests per second you can increase the number of clients.
viewsPerPost - the stress test will use this number to create a ratio of page views per posts (writes). In our example we have set "20" so there will be 20 page view requests for each write request. You can specify "0" to test only posts.
http%3A// - the beginning of the URL of the main server. %3A is the URL-quoted numeric value for ":". URL-quoted values are used here to avoid interpretation before being processed as a stress command.
ipAddress - the numeric IP address of the main Web Crossing server. The server we wish to test in our example is running at 202.219.13.82.
/cgi-bin/webx - the rest of the path to your main server. Our main server is running as a CGI with a script name of Web Crossing. You will need to change this part to fit the full URL path to your Web Crossing main server.
%3F14%40 - This URL-quoted numeric gets evaluated at ?14@. 14 is the URL code to "show a location".
sysop%3A - sysop is the sysop login name on the main server. %3A is the URL-quoted value for the ":" character.
pwdMain - the password for the main server. In our example, the password is "supersecret".
%40/Test - this evaluates at "@Test". Test is the name of the Test folder we created in the top level of the main server for this stress test.

After issuing the stress test command the test commences. You can wait for the test to end or interrupt it at any time by issuing the command to show the test results report.

Viewing the Report

You can view the report showing the results of your stress test by entering the command:

http://secondURL?200@sysop:pwdSecond@204-0
Example:

http://www2.webxharbor.net/webx?200@sysop:tmppwd@204-0

SecondURL and tmppwd are defined above. The 204-0 command means to stop the stress test and issue a report.

Note: The format for issuing stress tests looks cumbersome and hard to remember. It is. So please, once you have created the complicated URL string needed to issue a stress test command, save it somewhere so you can use it again easy with COPY/PASTE. I save my stress test and stress test report URLs in my Macintosh "Notepad." It is easy to find there. (The Notepad acts as a handy, searchable free-form database for all sorts of miscellaneous information such as this.)

Stress Testing Chats

You can use a similar method for stress testing chat rooms by having the second Web Crossing server emulate incoming chat users. Please note that there is a fairly rigid setup for this test:

The chat room being tested must have an access list that permits guests to be participants. Not just simply "allow anonymous users," but a specific access list.
A standalone server must act as a client to the server being tested. This client server cannot be a fanout server of the main chat server, or otherwise connected to the main chat server.
On the client chat server, make sure chat is activated, then create a chat room with guest participant access enabled. After you create this room, note it's unique ID number (example: .ee6bcd7)
Do the same on the chat server being tested...create a room (or use an existing), set participant access for guests, abd note it's unique ID#.

The format for the stress test command URL is as follows (URLs here are broken for clarity, and so they appear correctly on the page, but these should be all one line):

http://ip.of.client.server/webx?200@ sysop:pw-of-client-server@.table-of-client-server @6-nn-ip.of.server.being.tested-webxPort- .table-of-room-being-tested-startMin-runMin- shutdownMin-messageSecs-hopSecs
Example:

http://www2.webxharbor.net/webx?200@ sysop:tmppwd@.ee6b3b4 @6-5-202.219.13.82-5000- .ee6b3b4-1-5- 4-3-60

The URL parts are as follows:

http://ip.of.client.server/webx - the full URL of your client Web Crossing server. In our example, we have our client Web Crossing server running at http://www2.webxharbor.net/webx.
?200@ - the URL code for running a stress test. When the second Web Crossing server sees this command it knows to interpret the rest of the URL as a command to issue stress test requests.
sysop:pw-of-client-server - sysop is the login name of the sysop and pw-of-client-server is the sysop password on the client server. In our example, we have set up the client server so that the sysop has the password "tmppwd".
@.table-of-client-server - the chat room unique ID of the chat room on the client server.
@6 - indicates the start of a chat stress command specification.
nn - the number of chat users to be emulated. We are emulating 5 users in our example.
ip.of.server.being.tested - the IP address of the chat server being tested.
webxPort - the port number for direct database access. You can set this port number and enable this feature in Control Panel > General Settings. You must have this feature enabled to do chat stress testing. We have set this port number to 5000 in our example.
.table-of-room-being-tested - the unique ID of the table or chat room you wish to stress test (on the main server, not the client server). In our example, this is chat room number .ee7b3b4.
startMin - this time, in minutes, is used to determine how long it will take for each test chat client to start up. A random time in this interval is used. We have set "1", so each chat client will start accessing within a random time during the first minute of the stress test.
runMin - the total run time for the test, in minutes. We have specified a 5 minute chat test.
shutDownMin - this is the opposite of startMin. Each test chat user will finish its own test at some random time in this interval, specified in minutes. In our example, each user will quit during at a random time sometime within 4 minutes of accessing.
messageSecs - each test user will send a message at some random time during this interval, specified in seconds. In our case, our test users will send chat messages at least every 3 seconds.
hopSecs - each test user will randomly hop from table to table (if there are multiple tables in the chat room) during this interval, specified in seconds. We specified "60" in our example, so each user will change tables at some random time not longer than one minute.

When you enter this lengthly URL into your browser, the client server returns "Test started -- check log file for results," however there actually is no log file generated. What you need to do is enter the chat room on the main server to get a feel for how the response times are, and take this into consideration for you plans for the number of fanout servers and what-have-you.

Note: (These limitations do not apply to Unix servers - only to Mac and Windows servers) The Web Crossing direct-access service running at the control room only keeps 5 listens outstanding. If more than 5 test users are simultaneously trying to call the Web Crossing direct server, the excess test users will get a connection error and terminate. This is part of the reason why spreading out the users over some startup period is required (and also emulates real life).

Each chat fanout server only keeps 10 listens outstanding for clients. If more than 10 test users try to enter the chat server itself simultaneously, then the excess test users get an error and terminate.

As a result of these two limits, you may well see in the status panel that not all the users you were expecting actually arrived.

You can send multiple stress test commands out and each set of tests will run simultaneously. It is a good idea to build up a set of tests with 50 to 100 users to get a realistic feel for performance under busy conditions.

Troubleshooting

I can't get the stress test to run.

You most likely have made an error in the command format. You have to be careful to get all the punctuation marks correct. Other points to be careful about are making sure you have not mixed up your sysop passwords. The first password entered is the password of the second Web Crossing server - the one being used to execute stress test requests. Finally, don't forget to actually create the Test folder in the top-level of your main server. The stress test won't work without it.

I am getting a "service in use" error message after I set the direct database access feature on in the control panels.

You are using a port number already in use by your server machine. Do not use common port numbers such as 80 for HTTP or 23 for Telnet. Use a port number that is unlikely to be in use by another service. Read the section on Port Numbers for more information.

Resources

Sysop Docs

Web Crossing FAQ

Stress Testing