
I. Modes of Operation:
----------------------

AutoPerf can operate in 3 modes:

A. Profiling a single transaction at a specified load level
	java Master

B. Profiling a single transaction at multiple load levels
	java Master -c

C. Performing capacity analysis using probabilistic session generation
	java Master -c -p

In all the three modes, profilers need to be initiated at the server machines. Profilers can either be Linux profilers or Java Profilers. 
The linux profiler is started as:
./prof -d <port-no>

In the 3rd mode of opertaion, the tool also reads as input a CBMG from a file, whose path is specified in the 'config' file.

II. Tag details:
----------------

1. <transaction>
The <transaction> tag mainly consists of <name> and <url> tags.

name: an identifier with which a transaction definition can be identified.

url: the URL which is to be contacted to execute this transaction.
The default method used is 'GET'. In case of 'POST' method, and a transaction defined as <url method="post">http://a?b=c</url> the value of form variable 'b' is set to 'c' and the URL http://a is contacted. (i.e. URL is interpreted as that part before the '?', the rest is used to POST the variable values)

In the <url> tag, '&' has to be encoded as '&amp;' i.e. to connect to URL http://a?b=c&d=e we need to specify the url definition as: <url>http://a?b=c&amp;d=e</url>

A transaction such as 'read_email' might require logging into the system. More generically, suppose a transaction involves executing URL http://x, however, to execute it we need to have performed http://a, http://b and http://c previously. Such a transaction can be defined as:
<transaction>
<name>X1</name>
<initialisation>
http://a
http://b
http://c
</initialisation>
http://x
</transaction>

However, in capacity analysis mode of operation (mode 3), each such operation is defined by a seperate state. So http://a, http://b, http://c and http://x all form seperate transaction. The CBMG summarized the flow betweeen these transactions.

2. <compound_transaction>

This is useful when we need to treat execution of 2 consecutive URLs as a single transaction. It is just to add semantics to the input .xml file. Internally, it is treated exactly same as a <transaction> tag. However, <compound_transaction> can be used only in the first 2 modes.

In third mode of operation, <compound_transaction> cannot be used. Also, the order of <transaction> tags should be the same as that specified in the CBMG. Also, no extra transactions can be defined.

3. <thinktime> 

Optional tag. A global think time common to all transactions can be defined in the <farmer> tag. However, we can override that by a transaction-specific think time here.  

4. <timeout> 

Optional tag. Transaction specific timeout can be defined here. A timeout value of -1 means no timeouts. Default timeout value is -1 (i.e. no timeouts).

5. <sequencelist> 

Can be used to generate URLs dynamically. Elaborated more in the report. 

6. <farmer> 

In modes 1 & 2, a farmer defines a scenario, using the <usetransaction> tag, which specifies the transaction to be profiled. We can have multiple such <usetransaction> tags within a <farmer> tag. Also, we can have multiple <farmer> defined. Which <farmer> is to be profiled is decided by the <usefarmer> tag in the <farm> tag.

7. <executioncount>

This tag in the <farmer> tag is used to specify how many iterations of the transaction are to be performed by each of the emulated users. When no values is specified (<executioncount></executioncount>), the duration of load generation is determined automatically.

8. <warmup>

Takes boolean values: true or false. 

9. <NodeInfo> 

This tag specifies each of the deployed profilers, through the use of node, process and port tags. The node and process tags tell on which machine the profiler has been deployed and which process is being profiled by the profiler. The <port> tag tells the tool about the port on which the profiler is listening. This is needed for communication between the Master part of the tool and the profilers. 

The type of NodeInfo tell us whether the profiler is a Java profiler or not.
egs.
<NodeInfo type="NonJavaNode"> indicates a non java profiler.
<NodeInfo type="JavaNode"> indicates a java profiler.


** The tool can be operated in debug mode by changing log4j.rootCategory=warn to log4j.rootCategory=debug in the log4j.properties file.


