Addanc Reference Manual Addanc User Guide
	Brick User Guide

Introduction to Addanc Testing 

1. Arrival Rate Testing

1. 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.) the response. 
2. Script files must be generated by hand. There is, as yet, no nice AddancScript script capture tool.
3. 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.
4. 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. 
5. 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.
6. 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 is slowed 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.

2. Steps to Addanc Testing

1. Download and install Addanc.
2. Customize the configuration and logging configuration files.
3. Create a script using your favorite text or XML editor.
4. Use the script with a single brick; run a test to validate Addanc configuration, script, and/or tested application.
5. Create additional scripts to represent mix of work requests for the tested application. Test each script on a single brick.
6. Run the test using a single brick, or
7. Use AddancCommander to manage and monitor:
1. multiple bricks to generate  high test traffic arrival rates, and/or,
2. multiple instances to manage mix of scripts. 
8. Examine the test's instrumentation file to understand the response time behavior of the tested application while under load.

3. Addanc Scaling - Multiple instances on a single workstation/server

1. 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 threads. 
2. To let Addanc Brick access the full capacity of a multi-processor configuration, you can run multiple copies of the Addanc Brick on the workstation/server.
3. Multiple instances of Addanc Brick on a single workstation/server can supply a test load composed of a mix of scripts.
4. 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.

4. Addanc Scaling - Multiple workstations/servers

1. There may be multiple reasons for running AddancBrick across several workstations/servers:
1. When the required test load exceeds the generation capacity of a single workstation/server.
2. When the test load should be geographically generated.
3. When test requires test loads with multiple IP source addresses.
2. 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.
3. The single Addanc Commander and 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.