1. First, ensure the environment for load testing is consistent for all participating machines (ie. Controller and Load Generators). As the scripts are sent to the Load Generator to be executed, it must have the same environmental settings of the recorded scripts (in VuGen). For example, if the script was recorded in RMI-Java, JDK 1.4 exists on the machine that performed the recording. In the same context, the Load Generator will also require the JDK 1.4 to be installed on it for the script to execute properly. Therefore, ensure JDK versions are installed and similar to the recording machine.

Another example is an activity of uploading of a file by the script. If the script points to a directory that only exists in the recording machine, the Load Generator will require to create the same directory for it to be executed correctly with a copy of the designated file too.

2. Prior the scenario execution, conduct a trial run of about 10% of the actual load. This will weed out and ensure your scripts and parameters are working.

3. Once you are satisfied with the 10% load, turn off all the logs (especially Full Extended Log). These options will create an overhead on the entire load test which may skew the final results.

4. Do not panic when errors occurred during a scenario execution and start posting on Yahoo Groups for quick-and-dirty answers. What the tool does is to find out problems, right? When errors start to occur during a scenario execution, what you should do is to scope down the possibility of the errors. Use the following questions to help you with it.

1. Does it happen at the start of the scenario execution?
2. Does it happen at the middle of the scenario execution?
3. If (2), is yes, then how many Vusers were running at that point of time when the errors appeared?

With the above, you can determine if the scenario is actually failing due to the following reasons to list a few.

1. The script is not working properly in the first place or configuration of the script failed.
2. The application is experiencing load during the scenario execution.
3. Network/server issues not pertaining to load have occurred during the scenario execution.

When the scenario starts executing, the Controller dispatches the Vusers (scripts) to the Load Generators for execution. The Vusers are then executed on the Load Generator in memory with the pre-defined amount on behalf of the Controller. These vusers in terms generate the network traffic towards the application.The data generated by the Load Generator prior Collation process (discussed later) is stored in its default temp directory. The temp directory of the Controller and Load Generator serves different purposes. For the Controller, it stores the entire result data of the scenario execution whereas, the Load Generator stores the data of its own during the scenario execution. This can be configured before the execution under the Load Generator setup if required.

Note that if your load test stretches a (1) long duration, (2) contain additional logs or (3) you foresee a large amount of data to be generated, it is advisable to ensure that you have sufficient space for the temp directory in the Load Generator. It also applies to the Controller temp directory. Either increase the disk size for the temp folder or direct it to a folder that has a larger space.

During the execution, the real time data of the monitored servers are logged as event files in the Load Generators, at the same time, they are displayed in the graphs. At the end of the test, they are collated (in the later section) to be combine as a single result directory.

When the scenario completes, either (1) the Vusers finished execution, (2) you pressed the “Stop” button or (3) the duration of the load test have reached, the Vusers will gradually exit the scenario. Once all Vusers totally exited, the Controller goes into a Collation process.

In the Collation process, data regarding the execution (event files) that are stored in the temp directory of the Load Generator, are been sent back to the Controller to be compiled to one single result data. This is stored in the default folder of the temp directory in Controller, usually in C:\Documents and Settings with the folder name res. The actual file that describes the result is stored as .lrr file extension. With this file, you can launch Analysis to perform analyzing work of the load test.

1. The scenario is started from Controller.

2. Scripts are sent from the Controller to the Load Generators for execution.

3. Scripts are executed on the Load Generator in memory.

4. Network traffic from the scripts (vuser) are generated and sent to the application.

5. While the load test is been executed, transaction timing, monitoring data and information regarding the load test are being created as event files and stored in the temp directory of the Load Generator.

6. When the scenario completes, the event files of each Load Generators are being sent back to the Controller in the Collation process to compile as a single result directory in the Controller.