|
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 main chat server. 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 main chat server...create a room (or use an existing), set participant access for guests, 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://secondURL?200@sysop:password@.xxxxxxx@6-
nn-webxIp-webxPort-.table-
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://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".
- @Xxxxxxx
- 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.
- webxIp
- the IP address of the main (not client) chat server.
- 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
- 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
|
