Share this page

# Plan implementation

This task describes how to plan the hardware and software implementation as part of the load test planning process.

In this topic:

## Define the scope of performance measurements

You can measure response time at different points in the application. Determine where to run the Vusers and which Vusers to run according to the test objectives:

- Measuring end-to-end response time. You can measure the response time that a typical user experiences by running a GUI Vuser at the front end. GUI Vusers emulate real users by submitting input to and receiving output from the client application.

  You can run GUI Vusers at the front end to measure the response time across the entire network, including a terminal emulator or GUI front end, network, and server.

- Measuring network and server response times. You can measure network and server response time, excluding response time of the GUI front end, by running Vusers (not GUI) on the client machine. Vusers emulate client calls to the server without the user interface. When you run multiple Vusers on the client machine, you can measure how the load affects network and server response time.

- Measuring GUI response time. You can determine how the client application interface affects response time by subtracting the previous two measurements:

  GUI response time = end-to-end - network and server

- Measuring server response time. You can measure the time it takes for the server to respond to a request without going across the network. When you run Vusers on a machine directly connected to the server, you can measure server performance.

- Measuring middleware-to-server response time. You can measure response time from the server to middleware if you have access to the middleware and its API. You can create Vusers with the middleware API and measure the middleware-server performance.

## Define Vuser activities

Create Vuser scripts based on your analysis of Vuser types, their typical tasks, and your test objectives. Since Vusers emulate the actions of a typical end-user, the Vuser scripts should include the typical end-user tasks. For example, to emulate an online banking client, you should create a Vuser script that performs typical banking tasks. You would browse the pages that you normally visit to transfer funds or check balances.

You decide which tasks to measure based on your test objectives and define transactions for these tasks. Transactions measure the time that it takes for the server to respond to tasks submitted by Vusers (end-to-end time). For example, to check the response time of a bank web server supplying an account balance, define a transaction for this task in the Vuser script.

In addition, you can emulate peak activity by using rendezvous points in your script. Rendezvous points instruct multiple Vusers to perform tasks at exactly the same time. For example, you can define a rendezvous to emulate 70 users simultaneously updating account information.

Note: You can also add JMeter scripts to your scenarios. For details, see JMeter tests.

## Select Vusers

Before you decide on the hardware configuration to use for testing, determine the number and type of Vusers required. To decide how many Vusers and which types to run, look at the typical usage model, combined with the testing objectives. Some general guidelines are:

- Use one or a few GUI users to emulate each type of typical user connection.

- Run multiple Vusers to generate the rest of the load for each user type.

For example, suppose that you have five kinds of users, each performing a different business process:

Usage Model | GUI | Other
--- | --- | ---
100 customer service users in New York (LAN connection) | 2 | 98
30 customers in Europe (dial-in ISDN connection) | 2 | 28
5 background batch processes | _ | 5
150 customers (terminal connection) | _ | _
6 managers | 2 | 4

## Testing machine requirements

The hardware and software should be powerful and fast enough to emulate the required number of virtual users. Refer to the Support Matrix for specific hardware requirements.

To decide on the number of machines and correct configuration, consider the following:

- It is advisable to run Controller on a separate machine.

- Each GUI Vuser requires a separate Windows-based machine; several GUI Vusers can run on a single Linux machine.

  Note: If you plan to run your Vuser scripts on Linux-based load generators, it is recommended that you first test Linux compatibility for the scripts in VuGen. For details, see Check Linux Compatibility.

- Configuration of the test machine for GUI Vusers should be as similar as possible to the actual user's machine.

Note: The results file requires a few MB of disk space for a long scenario run with many transactions. The load generators also require a few MB of disk space for temporary files if there is no NFS. For more information about runtime file storage, see Runtime file storage locations.

## Vusers capacity on a load generator

During testing done on a large scenario with a strong VM machine, the following setup was proved to sustain 2000-2500 Vusers (and possibly more):

- 8 Core CPU

- 32 GIG of RAM

- 160 HD

- Network 1 GIG card

Notes on achieving this capacity:

- This is for web protocol usage. The number of Vusers may be less with non-web protocols.

- Deactivate Vmotion/generic allocation settings, depending on the virtualization server type.

- Monitor private cloud servers (like ESX matrix) to make sure the VM server is not overloaded.

- Results may be affected by factors such as AUT, business processes, or coding efficiency.

https://admhelp.microfocus.com Professional Performance Engineering,VuGen 8942
Tips to improve your search results... OpenText™ Professional Performance Engineering Help Center OpenText™ Professional Performance Engineering Help 26.1-26.3 All View Local Help Center View Online Help Center Version: