 |
Claims  |
|
|
What is claimed and desired to be secured by United States Letters Patent
is:
1. In a system including multiple clients communicating with a server,
wherein the server receives requests from the multiple clients, a method
for using a single processor for simulating the multiple clients for
testing a server stress, said method comprising the steps of:
initiating execution of a send data thread for selecting one of the
simulated multiple clients, wherein each of the simulated multiple clients
is controlled by said send data thread of the single processor, said send
data thread being adapted to initiate a plurality of I/O requests that
result in a transmission being sent to said server for each of said
simulated multiple clients;
initiating execution of a receive data thread, said receive data thread
being adapted to process completed I/O requests initiated by said send
data thread for each of said simulated multiple clients;
providing a data array wherein are stored state variables, each of said
state variables representing a simulated state of one of said simulated
multiple clients;
selecting, by said send data thread, one of said state variables and
initiating an I/O request in response to said selected one of said state
variables; and
receiving, by said receive data thread, notification of completion of said
initiated I/O request and updating in said data array said selected one of
said state variables.
2. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 1, said method
further comprising:
executing more than once said step of selecting, by said send data thread,
one of said state variables and initiating an I/O request in response to
said selected one of said state variables; and
executing more than once said step of receiving, by said receive data
thread, notification of completion of said initiated I/O request and
updating in said data array said selected one of said state variables.
3. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 2, further
comprising the step of comparing the completion frequency at which
notifications of completion of said I/O requests are received by said send
data thread to the initiation frequency at which said I/O requests are
initiated by said receive data thread.
4. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 1, further
comprising the step of measuring a response time for said initiated I/O
request, said response time being defined as the duration of time that
elapses between initiating said I/O request and receiving said
notification of said completion of said I/O request.
5. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 1, further
comprising the steps of:
said send data thread waiting a specified amount of time after initiating
said I/O request; and
initiating, by said send data thread, a second I/O request.
6. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 1, wherein
initiating said I/O request comprises selecting one of a plurality of
possible I/O requests that are associated with the simulated state
represented by said selected one of said state variables.
7. A method for using a single processor for simulating the multiple
clients for testing a server stress as defined in claim 6, wherein each of
said plurality of possible I/O requests has associated therewith a
relative frequency such that selecting one of said plurality of possible
I/O requests is conducted according to a predetermined probability.
8. In a system including a test client in communication with a server,
wherein the server is configured to communicate with multiple clients, a
method for simulating multiple clients on the test client for testing a
server, said method comprising the test client performing acts of:
initiating a send data thread, said send data thread being adapted to
initiate I/O requests that will result in a transmission being sent to
said server, for each of the simulated multiple clients;
initiating a receive data thread, said receive data thread being adapted to
process completed I/O requests initiated by said send data thread, for
each of the simulated multiple clients;
providing a data array wherein are stored state variables, each of said
state variables representing a simulated state of one of the simulated
multiple clients;
repeating more than once for each of the simulated multiple clients, by
said send data thread, the steps of:
selecting one of said state variables; and
initiating an I/O request in response to said selected one of said state
variables; and
repeating more than once for each of the simulated multiple clients, by
said receive data thread, the steps of:
determining whether said completed I/O request indicates that the simulated
state of one of the simulated multiple clients is to be updated; and
if said completed I/O request indicates that said simulated state of said
one of the simulated multiple clients is to be updated, updating in said
data array the state variable that represents said simulated state of said
one of the simulated multiple clients.
9. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, further comprising the steps of:
initiating a software object adapted to monitor said server to detect said
completed I/O request;
detecting, by said software object, said completed I/O request; and
sending, by said software object, notification of said completed I/O
request to said receive data thread.
10. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, wherein said notification of said
completed I/O request includes a parameter identifying one of the
simulated multiple clients with which said completed I/O request is
associated.
11. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, wherein said initiated I/O requests are
selected such that said simulated multiple clients simulate local area
network clients.
12. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, wherein said initiated I/O requests are
selected such that said simulated multiple clients simulate wide area
network clients.
13. A method for simulating multiple clients on the test client for testing
a server as defined in claim 12, wherein said simulated wide area network
clients are Internet clients.
14. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, wherein said initiated I/O requests are
selected such that said simulated multiple clients simulate chat server
clients.
15. A method for simulating multiple clients on the test client for testing
a server as defined in claim 8, comprising the step of reading and
applying state transition rules in order to select one of a plurality of
possible I/O requests that are associated with the simulated state that is
represented by said selected one of said state variables.
16. In a system including a server that communicates with multiple clients,
wherein an ability of the server to service multiple requests from the
multiple clients is unknown, a method for simulating multiple clients for
testing a server, said method comprising the steps of:
initiating a single send data thread for the simulated multiple clients,
said send data thread being adapted to initiate I/O requests that will
result in a transmission being sent to said server;
initiating a single receive data thread for the simulated multiple clients,
said receive data thread being adapted to process completed I/O requests
initiated by said send data thread;
providing a data array having stored therein at least a first state
variable that represents a first simulated state and a second state
variable that represents a second simulated state, said first simulated
state being associated with a first simulated client and said second
simulated state being associated with a second simulated client;
initiating, by said send data thread, a first I/O request associated with
said first simulated client and a second I/O request associated with said
second simulated client:
receiving, by said receive data thread, notification of completion of one
of said first I/O request and said second I/O request; and
updating, by said receive data thread, one of said first state variable and
said second state variable selected in response to said completion of one
of said first I/O request and said second I/O request.
17. A computer program product for implementing, in a system including a
server in communication with multiple clients, wherein an ability of the
server to service multiple requests from the multiple clients is unknown,
a method for testing the ability of the server to service multiple
requests by having a test client simulate the multiple clients, the
computer program product comprising:
a computer-readable medium having computer-executable instructions for
implementing the method, the method comprising acts of:
storing a plurality of simulated client profiles each representing an
associated simulated client, each of said simulated clients profiles
comprising client profile data including at least a simulated client
state;
sending I/O requests on behalf of all of said simulated multiple clients
using a send thread, wherein the act of sending further comprises:
selecting one of said simulated client profiles in order to initiate a
client action on behalf of the associated simulated client;
initiating an I/O request to a server in order to simulate said client
action with the send thread; and
monitoring the completion status of all I/O requests initiated by the send
thread;
receiving completed I/O requests on behalf of all of said simulated clients
using a receive thread, the act of receiving further comprising:
receiving notification of a completed I/O request associated with one of
said simulated clients; and
updating the simulated client state associated with said simulated client
in accordance with said completed I/O request.
18. A computer program product as defined in claim 17, further comprising
an act of measuring a response time for one of said I/O requests, wherein
said response time is defined as the duration of time that elapses between
initiating said one of said I/O requests and receiving notification of
completion of said one of said I/O requests.
19. A computer program product as defined in claim 17, wherein said act of
sending comprises one executable software thread for sending said I/O
requests on behalf of all of said simulated clients.
20. A computer program product as defined in claim 17, wherein said
computer-executable instructions are executed by one or more computer
processors and wherein said act of sending comprises a number of
executable software threads equal to the number of said one or more
computer processors.
21. A computer program product as defined in claim 17, wherein said act of
receiving completed I/O requests further comprises means for identifying
said one of said simulated clients that is associated with said completed
I/O request.
22. A computer program product as defined in claim 21, wherein said act of
receiving competed I/O requests further comprises means for determining
whether said completed I/O request indicates that at least one of said
simulated client states is to be changed.
23. A computer program product as defined in claim 17, wherein said act of
selecting one of said simulated client profiles comprises an act of
specifying one of said simulated clients on whose behalf said client
action is to be initiated.
24. A computer program product as defined in claim 17, wherein said act of
sending further comprises an act of storing state transition rules that
define possible simulated client states and that associate with each of
said possible simulated client states at least one possible I/O request.
25. A computer program product as defined in claim 24, wherein said act of
selecting further comprises an act of reading said state transition rules
in order to select, from among said at least one possible I/O request, the
I/O request that is to be initiated by said means for initiating.
26. A computer program product as defined in claim 17, wherein said act of
sending further comprises an act of delaying, such that a selected amount
of time elapses between initiation of an I/O request by said means for
initiation and subsequent selection of one of said simulated client
profiles by said means for selecting. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The present invention relates to stress testing of network servers, wherein
a plurality of concurrent network clients are simulated. More
particularly, the present invention relates to stress testing of a network
server in which multiple clients are simulated by executing one executable
software thread on each of one or more processors, whereby I/O requests
are initiated to the server on behalf of all clients. The stress testing
of the present invention further includes executing another executable
software thread on each of the one or more processors, whereby I/O
response data from the server is received on behalf of all clients.
2. The Prior State of the Art
In recent years, use of servers has become common in both local area and
wide area networks. Such networks allow multiple computer users to access
the processing capabilities of the network server. In local area networks,
network users can share information and gain access to software
applications stored and executed in the server. Local area networks are
also useful for providing rapid and convenient communication between
users. Relatively inexpensive terminals can benefit from the typically
more powerful computing capabilities of the server.
Wide area networks, such as the Internet, have become popular due to the
ease with which network users at remote locations are able to retrieve and
share information. For example, World Wide Web servers allow remote users
to download text, graphics, multimedia materials, or to take advantage of
network applications stored and executed by the server. Electronic mail
servers present users with a quick and convenient means of
telecommunication. Chat servers have also become increasingly popular in
large measure for their ability to provide real-time communication between
remote users. Users of a networked chat service can select from a great
number of topics, join a chat service channel, and contribute to an
ongoing discussion on the topic. Chat services can have substantial
entertainment, informational, and educational value. It can be expected
that in coming years, local area and wide area networks will become
increasingly important as the related technology becomes more widespread
and accepted.
One of the significant advantages of network servers is that they provide
processing services to multiple concurrent clients. It is important for a
network provider to ensure that a server is powerful enough to service a
large number of simultaneous clients at peak times. Many network users,
particularly of the Internet, have experienced delayed response times
during hours of high usage. When a network provider fails to maintain a
server with sufficient speed and multiple client capability, the
inconvenienced users are often frustrated and can lose interest in the
services of the network provider. However, it is often difficult to
predict beforehand how a server will respond to high volumes of file
uploads or downloads or other input/output (I/O) requests and client
actions. Often, a network provider does not discover that server resources
are inadequate until after a large number of clients are inconvenienced.
It is particularly important to ensure that sufficient server capabilities
are on hand when a network provider stages a well publicized chat session.
For example, it has become increasingly common for chat server providers
to advertise for and provide sessions in which users may communicate with
celebrities. In such cases, it is common to receive requests for access
from remote users in volumes that are much greater than those of typical
chat sessions. Network providers who conduct such large-volume chat
sessions naturally want to have adequate server capabilities, but may find
it difficult to know if their resources are sufficient. When hundreds or
thousands of simultaneous users are expected to generate I/O requests to a
server installation, it is impractical to conduct tests using actual
clients, and it may be impossible to rely on past experience.
In order to predict whether a chat server, or any other network server, is
powerful enough to handle peak volume of a specified magnitude, there have
been developed test methods of simulating multiple concurrent network
clients to the server. Seen in FIGS. 1 and 2 is one such method that is
known in the art. FIG. 1 illustrates the arrangement and relationship of
elements within a client simulator computer and the network, while FIG. 2
depicts the steps of the method in flow chart form.
Referring now to FIG. 1, at least one client simulator computer is
connected to server 60 in order to provide simulated I/O requests.
Executable software threads are initiated and dedicated to each of a
plurality of simulated clients in a one-to-one relationship. Accordingly,
if a test is designed to simulate 1,000 concurrent clients, there will be
1,000 dedicated client threads 62. Each dedicated client thread 62 is
associated with a client profile 64 for one of the simulated clients.
Dedicated client thread 62 initiates and sends I/O requests on behalf of
its simulated client to an associated socket 68. The I/O requests are
forwarded through network communication infrastructure 70 to server 60. A
switching module 66, such as a context switching routine or the like, is
used to assign one of the dedicated client threads 62 to the processor of
the client simulator computer. If the client simulator computer has only
one processor, only one of dedicated client threads 62 may run at any one
time.
Each client profile 64 typically assigns to the simulated client a set of
simulated characteristics, such as the frequency of making I/O requests,
the type of I/O requests to be made, and the states that are possible. For
example, a first simulated client may be designated as a normal chat
client who makes I/O requests every 30 seconds on average. The first
simulated client may be allowed to join a chat channel from the logged-on
state and to make a series of I/O request, 95% of which may be talk
messages to the server, with 5% being requests to part or exit the
channel. A second simulated client may be designated as one who joins the
channel and does little more than read posted messages while contributing
none of its own. Another simulated client may be designated as a host,
while still another may be assigned to be the systems operator (sysop). In
any event, client profiles 64 are designed to mimic the actions that
actual network clients are likely to make.
Each dedicated client thread 62 repeatedly reads and updates the
information stored in the associated client profile 64. In operation, a
dedicated client thread 62 executes step 72 of FIG. 2 by reading and
evaluating the state of its simulated client from the associated client
profile 64. For example, it may be determined that the simulated client is
in a logged-on state. Next, in step 74, dedicated client thread 62 selects
an I/O request for its simulated client from among the permissible
requests for a client in the logged-on state. For example, a request to
join a chat channel may be selected. In step 78, the I/O request is
initiated and sent to an associated socket 68 and in turn sent through the
network communication infrastructure 70 to the server 60.
After sending an I/O request, the dedicated client thread 62 waits, in step
80, for a response from server 60. When the I/O request is completed, I/O
response data thereby generated is sent from server 60 back to the
appropriate socket 68 through network communication infrastructure 70. The
associated dedicated client thread 62 detects the response to the I/O
request and retrieves information from its socket 68 in step 82. Dedicated
client thread 62 then determines, according to step 84, whether the
response indicates that the state of the associated simulated client
should be changed, for example, from logged-in to in-channel. According to
step 86, if no change is to be made, the routine reverts to step 72. If
the simulated client should be moved to a new state, the appropriate
changes are made in client profile 64, as shown in step 88, after which
dedicated client thread 62 is ready to begin the cycle once again. At any
time during execution of the foregoing steps, dedicated client thread 62
is generally subject to losing and regaining access to the processor
according to a switching protocol executed by switching module 66.
A suitable stress test should satisfy at least four criteria. First, the
simulated clients must perform a wide variety of actions that closely
approximate the behavior of actual clients. Second, the number of
simulated clients must be as large as desired. Third, the method used for
simulating clients must be fast enough to handle the response from the
server so as not to create an artificial bottleneck. Finally, the method
is preferably generic so that it can be customized to simulate a wide
variety of clients and client behavior.
The foregoing prior art method of assigning each simulated client a
dedicated thread becomes inefficient once the number of simulated clients
becomes sufficiently large. Thus, the known methods do not satisfactorily
meet the second of the criteria listed above in that the number of clients
that may be simulated is limited. When there are many clients, context
switching between threads consumes a large portion of the resources of the
simulating machine. This can cause the results of the stress test to be
inadequate, since the simulation may not be able to generate I/O requests
as quickly as would be required. It has been found that an appreciable
amount of computer resources may be consumed in context switching between
as few as 40 dedicated client threads.
Further, conventional operating systems on which the prior art stress
testing systems are conducted typically have structural limits to the
number of executable threads that may be supported. For instance,
Microsoft Windows NT scales to about 2,000 threads. Accordingly, stress
tests running on a Windows NT system with only one processor have been
limited to about 2,000 simulated clients. This is unsatisfactory for
testing servers that may be called on to serve many times that number of
actual clients.
It would, therefore, be desirable to have a stress testing method to
simulate a number of clients that is larger than the number of threads
supported by conventional operating systems. In particular, it would be
advantageous to provide a stress testing method to simulate a number of
clients that is not limited by the operating system or the context
switching capabilities of the machine on which it runs. It would be
advantageous to provide a method for initiating I/O requests for a large
number of simulated clients wherein the amount of computer resources
dedicated to switching between executable threads is minimized. It would
also be desirable to have such a testing method that is flexible such that
a wide variety of servers could be tested.
SUMMARY OF THE INVENTION
The foregoing problems in the prior state of the art have been successfully
overcome by the present invention According to the invention, I/O requests
are initiated on behalf of as many simulated clients as desired using a
number of executable software threads that is optimally equal to the
number of processors that are used to conduct the stress test. Likewise,
I/O response data is received on behalf of all simulated clients using a
number of executable threads that is optimally equal to the number of
processors. For example, if a single processor is used, one executable
software thread is provided for initiating all I/O requests, while a
second executable software thread is used to receive all I/O response
data. A system having, for example, three processors will optimally use
three executable threads for generating I/O requests and three executable
threads for receiving I/O response data.
The stress test of the present invention is not limited by the number of
executable threads that is supported by the operating system that is used.
The present invention is enabled by completion port or similar technology,
which allows all I/O requests to be initiated by executing one thread, the
send data thread, on each processor, and which further allows all I/O
response data to be received by executing another thread, the receive data
thread, on each processor.
A completion port is a software object supported by Microsoft Windows NT
operating system software version 3.5 and later that monitors the status
of a plurality of overlapped or copending I/O requests to detect
completion of one of the I/O requests. The completion port associates a
parameter with the completed I/O request that it detects. The parameter is
then used by the system of the present invention to identify the simulated
client on whose behalf the completed I/O request has been initiated. As a
result, the receive data thread can respond to the completed I/O request
on behalf of the appropriate simulated client. Accordingly, instead of
each simulated client needing its own dedicated client thread, use of
completion port technology as described herein allows one receive data
thread to service all simulated clients. However, the invention is not
limited to completion port technology. Instead, the invention extends, for
example, to any similar routine, program, object, component, or the like
that can notify a receive data thread of completion of one of multiple
copending I/O requests.
According to a method of conducting the stress test under the invention, a
client simulator computer configured to support completion ports or
similar technology is connected to the server that is to be tested. The
client simulator has stored therein client profiles associated with
clients to be simulated. State variables contained in the client profiles
are updated as needed to reflect the server's ongoing responses to the I/O
requests of the associated simulated clients. Each client profile also
assigns a usage profile to a simulated client. For example, a usage
profile may include a predetermined frequency with which the associated
simulated client is to initiate I/O requests. The usage profile may also
specify the types of I/O requests that the simulated client can initiate.
The client profile further includes a set of state transition rules that
correspond to each of the possible states in which a simulated client may
be. The rules define the range of possible I/O requests associated with
the various states and the basic behavior of the simulated clients. The
elements of the client profile are provided such that the actions of the
simulated clients closely resemble activity initiated by actual clients on
a network.
The stress test is conducted as the send data thread selects one of the
simulated clients. The send data thread reads the state of the simulated
client from a simulated client state array. In response to the state that
is thereby read, the send data thread selects an appropriate I/O request
for the selected simulated client by reading and applying the state
transition rules and the usage profile. The send data thread then
initiates the I/O request that has been selected and sends the I/O request
to an associated socket.
The I/O request is transmitted from a socket to the server by means of
network communication infrastructure. Meanwhile, the send data thread can
wait a specified delay interval before again selecting the next simulated
client. The send data thread repeats the cycle for the newly selected
simulated client. Accordingly, the send data thread initiates multiple I/O
requests in series. The specified delay interval is generally selected
such that the frequency at which the send data thread initiates I/O
requests closely resembles the frequency for which the server may receive
requests during actual use.
The server processes the I/O requests initiated by the send data thread.
The method of stress testing is such that from the standpoint of the
server, the incoming I/O requests are essentially indistinguishable from
those of actual clients. The server transmits I/O response data associated
with completed I/O requests back to the sockets, which is subsequently
passed on to one of a plurality of client data buffers. During this
process, a completion port continuously monitors the sockets for a
completed I/O requests. Each time such a completed I/O request is
detected, the completion port notifies a receive data thread of the
completion. The notification includes a parameter that the receive data
thread uses to associate the completed I/O request with the appropriate
simulated client.
Is The notification from the completion port signals the receive data
thread to read the I/O response data contained in the client data buffer
associated with the appropriate simulated client. The receive data thread
determines whether the completed I/O request indicates that the state of
the simulated client should be changed. If the state should be changed,
the receive data thread updates the value of the associated state variable
in the client profile to represent the new state.
The invention typically also includes structure and steps for monitoring
the performance of the server. This may be accomplished in one of at least
two ways. First the method may include measuring the elapsed time between
initiation of a specified I/O request and completion thereof by the
server. This process can be extended to identify response times for any or
all I/O requests. The maximum response time for any request may be
measured and an average response time can be calculated. Second, the
completion frequency at which the server successfully completes I/O
requests can be measured. The completion frequency may be compared with
the initiation frequency, or the rate at which the server receives I/O
requests. A completion frequency that is regularly less than the
initiation frequency would suggest that the server tends to accumulate an
I/O backlog and cannot keep up with demand or that an inordinate number of
I/O requests are unsuccessful.
It will be appreciated that the present inventive method overcomes the
limitations in the prior art. The stress test of the present invention is
not inherently limited to a maximum number of clients because only one
thread per processor is needed to initiate requests on behalf of all
clients. Moreover, response time for the stress testing application is
improved because the client simulator computer does not need to allocate
large amounts of processing power to context switching between many
executable threads. The present invention is a great improvement in the
prior art since context switching in single processor systems is conducted
only between the send data thread and the receive data thread.
The present invention is able to simulate a wide variety of client actions.
The methods are sufficiently flexible to simulate clients of a large range
of servers. The stress test may be modified to correspond to differing
levels of usage, numbers of clients, and types of I/O requests.
Additional objects and advantages of the invention will be set forth in the
description which follows, and in part will be obvious from the
description, or may be learned by the practice of the invention. The
objects and advantages of the invention may be realized and obtained by
means of the instruments and combinations particularly pointed out in the
appended claims. These and other objects and features of the present
invention will become more fully apparent from the following description
and appended claims, or may be learned by the practice of the invention as
set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the manner in which the above-recited and other advantages
and objects of the invention are obtained, a more particular description
of the invention briefly described above will be rendered by reference to
specific embodiments thereof which are illustrated in the appended
drawings. Understanding that these drawings depict only typical
embodiments of the invention and are not therefore to be considered to be
limiting of its scope, the invention will be described and explained with
additional specificity and detail through the use of the accompanying
drawings in which:
FIG. 1 is a block diagram of selected elements of a prior art system for
conducting a stress test of a server;
FIG. 2 is a flow chart of the prior art stress test method of FIG. 1;
FIG. 3 is an example system that provides a suitable operating environment
for the present invention;
FIG. 4 is a block diagram showing a hardware, software, and network
environment in which a stress test of the invention may be conducted;
FIG. 5 is a block diagram of selected elements of the system of the present
invention for conducting a stress test of a server;
FIG. 6 is a block diagram showing elements of the send data thread of FIG.
5 to further illustrate the process of selecting and initiating I/O
requests;
FIG. 7 is a flow chart showing the steps executed by the send data thread
of FIG. 6;
FIG. 8 is a block diagram showing elements of the receive data thread of
FIG. 5 to further illustrate the method of receiving notification of
completed I/O requests and of updating the states of the simulated
clients;
FIG. 9 is a flow chart showing the steps executed by the receive data
thread of FIG. 8;
FIG. 10 is a state diagram presenting an example of states in which a
simulated chat server client may reside in relation to a chat server and
showing selected I/O requests that may be initiated on behalf of clients
in the various states;
FIG. 11 is a state diagram for a simulated host client that expands on the
state diagram of FIG. 10; and
FIG. 12 is a state diagram for a simulated systems operator client that
expands on the state diagram of FIG. 10.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The invention is described below by using diagrams to illustrate either the
structure or processing of embodiments used to implement the system and
method of the present invention. Using the diagrams in this manner to
present the invention should not be construed as limiting of its scope.
The present invention contemplates both methods and systems for simulating
multiple clients for stress testing a network server. The embodiments of
the present invention may comprise a special purpose or general purpose
computer comprising various computer hardware, as discussed in greater
detail below.
Embodiments within the scope of the present invention also include computer
readable media having executable instructions or data fields stored
thereon. Such computer readable media can be any available media which can
be accessed by a general purpose or special purpose computer. By way of
example, and not limitation, such computer readable media can comprise
RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk
storage or other magnetic storage devices, or any other medium which can
be used to store the desired executable instructions or data fields and
which can be accessed by a general purpose or special purpose computer.
Combinations of the above should also be included within the scope of
computer readable media. Executable instructions comprise, for example,
instructions and data which cause a general purpose computer, special
purpose computer, or special purpose processing device to perform a
certain function or group of functions.
FIG. 3 and the following discussion are intended to provide a brief,
general description of a suitable computing environment in which the
intention may be implemented. Although not required, the invention will be
described in the general context of computer-executable instructions, such
as program modules, being executed by a personal computer. Generally,
program modules include routines, programs, objects, components, data
structures, etc. that perform particular tasks or implement particular
abstract data types. Moreover, those skilled in the art will appreciate
that the invention may be practiced with other computer system
configurations, including hand-held devices, multi-processor systems,
microprocessor-based or programmable consumer electronics, network PCs,
minicomputers, mainframe computers, and the like. The invention may also
be practiced in distributed computing environments where tasks are
performed by remote processing devices that are linked through a
communications network. In a distributed computing environment, program
modules may be located in both local and remote memory storage devices.
With reference to FIG. 3, an exemplary system for implementing the
invention includes a general purpose computing device in the form of a
conventional computer 20, including a processing unit 21, a system memory
22, and a system bus 23 that couples various system components including
the system memory to the processing unit 21. The system bus 23 may be any
of several types of bus structures including a memory bus or memory
controller, a peripheral bus, and a local bus using any of a variety of
bus architectures. The system memory includes read only memory (ROM) 24
and random access memory (RAM) 25. A basic input/output system (BIOS) 26,
containing the basic routines that help to transfer information between
elements within the computer 20, such as during start-up, may be stored in
ROM 24. The computer 20 may also include a magnetic hard disk drive 27 for
reading from and writing to a magnetic hard disk, not shown, a magnetic
disk drive 28 for reading from or writing to a removable magnetic disk 29,
and an optical disk drive 30 for reading from or writing to removable
optical disk 31 such as a CD-ROM or other optical media. The magnetic hard
disk drive 27, magnetic disk drive 28, and optical disk drive 30 are
connected to the system bus 23 by a hard disk drive interface 32, a
magnetic disk drive interface 33, and an optical drive interface 34,
respectively. The drives and their associated computer-readable media
provide nonvolatile storage of computer readable instructions, data
structures, program modules and other data for the computer 20. Although
the exemplary environment described herein employs a magnetic hard disk
27, a removable magnetic disk 29 and a removable optical disk 31, it
should be appreciated by those skilled in the art that other types of
computer readable media which can store data that is accessible by a
computer, such as magnetic cassettes, flash memory cards, digital video
disks, Bernoulli cartridges, random access memories (RAMs), read only
memories (ROM), and the like, may also be used in the exemplary operating
environment.
A number of program modules may be stored on the hard disk, magnetic disk
29, optical disk 31, ROM 24 or RAM 25, including an operating system 35,
one or more application programs 36, other program modules 37, and program
data 38. A user may enter commands and information into the computer 20
through input devices such as a keyboard 40 and point device 42. Other
input devices (not shown) may include a microphone, joy stick, game pad,
satellite dish, scanner, or the like. These and other input devices are
often connected to the processing unit 21 though a serial port interface
46 that is coupled to system bus 23, but may be connected by other
interfaces, such as a parallel port, game port or a universal serial bus
(USB). A monitor 47 or other type of display device is also connected to
system bus 23 via an interface, such as video adapter 48. In addition to
the monitor, personal computers typically include other peripheral output
devices (not shown), such as speakers and printers.
The computer 20 may operate in a networked environment using logical
connections to one or more remote computers, such as a remote computer 49.
Remote computer 49 may be another personal computer, a server, a router, a
network PC, a peer device or other common network node, and typically
includes many or all of the elements described above relative to the
computer 20, although only a memory storage device 50 has been illustrated
in FIG. 3. The logical connections depicted in FIG. 3 include a local area
network (LAN) 51 and a wide area network (WAN) 52 that are presented here
by way of example and not limitation. Such networking environments are
commonplace in offices, enterprise-wide computer networks, intranets and
the Internet.
When used in a LAN networking environment, the computer 20 is connected to
the local network 51 through a network interface or adapter 53. When used
in a WAN networking environment, the computer 20 typically includes a
modem 54 or other means for establishing communications over the wide area
network 52, such as the Internet. The modem 54, which may be internal or
external, is connected to the system bus 23 via the serial port interface
46. In a networked environment, program modules depicted relative to the
computer 20, or portions thereof, may be sorted in the remote memory
storage device. It will be appreciated that the network connections shown
are exemplary and other means of establishing a communications link
between the computers may be used.
As used herein, "simulated client" includes any network user, computer, or
network-accessible device that is modeled by the stress test of the
present invention. A simulated client is defined in part by an associated
client profile that includes, for example, a set of possible states of the
simulated client, state transition rules that specify possible I/O
requests to a server from the simulated client in any of the possible
states and a relative frequency of each of the possible I/O requests. As
the client simulator computer initiates I/O requests on behalf of the
simulated client in accordance with the client profile, the simulated
client is, in effect, a virtual network user or device whose actions
simulate those of an actual client as reasonably closely as desired.
The term "state" is used herein to describe the relationship of the
simulated client with respect to the elements of the system of the
invention that include, but are not limited to, the server, the client
simulator computer, stored data, and the computer code of the stress test
application. A simulated client in a specified state is authorized and
constrained to interact with the elements of the system in a predetermined
manner. The state of a simulated client corresponds to the various levels
of access to a server and authorization to execute I/O requests that are
experienced by actual users. For example, an actual user may be
logged-off, logged-on, or have specific access to certain files on a
server. Likewise, analogous states may be assigned to a simulated client
to define the level of authorization and access of the simulated client.
Typically, the state of any simul | | |
