Client/Server - Stress testing
submit complex transactions to the server from each client in your test
network, using minimal user setup, you can emulate the typical load of a
much larger number of clients.
server system--even if your clients are submitting requests at top speed. In
this case it may be worthwhile to reconfigure your equipment so that your
server is less powerful. An inadequate server configuration should enable you
to test the server's management of peak server conditions.
data transfers, for 24 to 48 hours. One way to implement this is to use one set
of clients to generate large amounts of new data and another set to verify the
data (and delete data to keep the size of the database at an appropriate level).
You would need to synchronize the verification scripts to wait for the
generation scripts. The 4Test script language makes this easy. You would not
normally need a very large testbed to drive this type of server load, but again,
if you under-configure your server you will probably be able to exercise the
sections of the software that handle the outer limits of data capacity.
performance is achieved by actually testing the system in a real-world
environment, rather than through simulation. However, if it is impractical to
test the full scope of the system (500 users, for instance), you will typically
have a better understanding of the load on your system at this usage level by
projecting the actual system performance based on the real-world testing of a
subset of systems. Typically, the performance trend is reached long before all
users have been added, and the mathematical projection is a simple one:
then project the remainder. From the response times at different request rates,
you can calculate the expected performance for different numbers of users
submitting requests at a normal rate. The result of this method is frequently
more accurate than simulation can provide, because a simulation cannot
produce the same complex interactions as these scenarios.
realistic workload (which might average two server requests per client per
hour), you can design an artificial workload that submits sequential requests
as fast as the response to the previous request is received. If you cannot
generate a sufficient load using SilkTest's GUI-driving scripts, use the
Extension Kit (EK) to drive the application's API directly. Using either
method, you can drive the server with different rates of received requests and