|
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 isthe 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
|
