Addanc is a web application testing tool that focuses on
generating a test load that represents "real-world" traffic patterns
for the application under test. Addanc generates a test load composed
of simulated HTTP/HTTPS traffic from Virtual Clients (VCs) where new Virtual Clients
arrive requesting service at a defined arrival rate. The individual
HTTP/HTTPS transactions that make up the VC's total service request are
defined in the VC's Script.
The Script is simply a XML formatted list of URLs for Addanc to fetch.
The Script also specifies delays between HTTP/HTTPS transactions that
can be used to represent the time a VC spends
"processing" (reading, completing the form, looking at picture, etc.)
Script files must be generated by hand. There is, as yet, no
nice AddancScript script
Addanc is intended to be scalable, so multiple instances of the AddancBrick may
be run on a single workstation/server in order to provide a mix of test
scripts, or to achieve higher test arrival rates. Cooperating teams of
workstations/servers may run individual and/or multiple copies of the AddancBrick in
order to achieve sufficiently high test arrival rates.
The maximum number of VCs
supported by AddancBrick
is limited only by the capacity of the AddancBrick(s)
used for generating a test load. Addanc tests generate new VCs
according to the test's defined arrival rate. Each VC exists for a period of time
representing the time required to execute the VC's associated script, including
inter-page delays, if any. Therefore, if a script's expected elapsed
time is a large multiple of the inter-arrival gap (1/<arrival
rate>), the number of Active VCs
in an Addanc test will increase to some plateau; representing the
ability of the tested application to handle the workload generated by
the Addanc test. If the Active VC
count does not reach a plateau, the test load may exceed the workload
capacity of the tested application. Or, the script's expected elapsed
time is such a large multiple of the brick's defined inter-arrival gap
that the total number of Active VCs
required is very large.
To achieve high arrival rate testing when using scripts with
long expect elapsed times, spread the test load over multiple
workstations/servers. This will allow the AddancBrick instances
on each workstation/server to work at lower generation rates and thus
maintain a lower number of active VCs.
For example, to achieve a total test arrival rate of 150 VCs per minute. use 3 AddancBricks each
generating a test load with an arrival rate of 50 VC per minute.
Addanc tests generate a test load that is independent of the
work capacity of the tested application. The maximum test load
generated during an Addanc test is limited by the total capacity of the AddancBricks and
the allocation of the script mix to each AddancBrick. In
testing paradigms where the total test load is a function of a fixed
number of active VCs, an
application under test can influence the total test load presented to the
tested application, a situation commonly known as negative feedback. A saturated
application server can reduce the total test workload traffic because the total
arrival rate of requests for new service is governed by the completion
rate of each VC, and the completion rate
due to the saturated application. In this case, the completion rate may not accurately measure of the workload capacity (transaction rate) of
the tested application.
Steps to Addanc Testing
Download and install Addanc.
Customize the configuration and logging configuration files.
Create a script using your favorite text or XML editor.
Use the script with a single brick; run a test to validate Addanc configuration, script, and/or tested application.
Create additional scripts to represent mix of work requests for
the tested application. Test each script on a single brick.
Run the test using a single brick, or
manage and monitor:
multiple bricks to generate high test traffic arrival
multiple instances to manage mix of scripts.
Examine the test's instrumentation file to understand the
response time behavior of the tested application while under load.
Addanc Scaling - Multiple instances on a single
Addanc is written as a multi-threaded python application.
However, some people claim that multi-threaded python applications do
not scale when given access to a multi-processor configuration. Python
threads, it seems, don't really want to run as truly concurrent
To let Addanc Brick access
the full capacity of a multi-processor configuration, you can run
multiple copies of the Addanc Brick on
Multiple instances of Addanc Brick on
a single workstation/server can supply a test load composed of a mix of
Multiple instances of Addanc Brick on
a single workstation/server can be monitored and controlled using the Addanc Commander if
run in daemon mode and
granted access to a jabber server.
Addanc Scaling - Multiple workstations/servers
There may be multiple reasons for running AddancBrick across
When the required test load exceeds the generation capacity
of a single workstation/server.
When the test load should be geographically generated.
When test requires test loads with multiple IP source
Instances of Addanc Brick on
a multiple workstation/servers can be monitored and controlled using
the Addanc Commander if
each instance is run in daemon mode
with an unique Brick Id and granted access to a jabber server.
The single Addanc
multiple (possibly geographically distributed) Addanc Bricks supported
by inexpensive HW (sub $500.00US platform) is one of the key design
and implementation goals of the Addanc project.