Share this page

# Load test with TruClient scripts

The following tips can help you run your load tests with TruClient scripts.

In this topic:

## TruClient load overview

TruClient technology provides you with the ability to record complex business processes in a user-friendly interface. However, since TruClient records at the user level and requires a browser for replay, the more complex an application's client logic, the more CPU and memory it requires to run a Vuser.

As a result, the TruClient footprint can be significantly larger than the footprints of other Vuser protocols used to run a similar business process. You can use the tips in this topic to improve your load test results with TruClient scripts.

For TruClient - Web scripts, you also have the option to convert them to Web - HTTP/HTML scripts. The converted scripts can be used in load tests. For details, see Convert a TruClient script to Web - HTTP/HTML format.

## Replaying on different browsers

Generally, TruClient web protocols adjust to differences between supported browsers. Therefore, you can record on one browser and replay on any supported browser. However, before using a script in a load test on a particular browser, the script must be successfully run on that browser interactively.

Because much of the processing of a web page is performed by the browser, the differences between browsers can affect load testing. For example, there may be differences between browsers in:

- Render time
- Step end event
- Object identification
- Authentication
- Differences in feature sets between browsers

## Calculate the number of load generators

TruClient tests run on standard OneLG Vuser load generators:

- For TruClient 2.0 - Web scripts, the tests can be run on either Windows-based or Linux Ubuntu-based load generators.

- For all other TruClient scripts, the tests run on Windows-based load generators.

You can use the following method to determine the required number of load generators.

To calculate the number of load generators:

1. Record a TruClient script.

2. Replay a single Vuser in Controller and check the average CPU and the peak memory consumption of the mdrv.exe process and all its descendant processes by adding a counter for % Processor Time and Private Bytes.

3. Based on your load generator hardware and the CPU and memory consumption of a single Vuser, calculate the number of Vusers per machine.

   Example: In this example, each of the load generators has 8 core processors and 8GB of memory. A single Vuser in this example consumes 80MB of peak memory and 10% CPU on average for the specific business process.

   From a CPU perspective, if you limit the CPU consumption up to 70% utilization, you can have 7 Vusers per core processor (70% / 10%). If the load generator has a total of 8 cores processors, 8 * 7 Vusers per processor equals 56 Vusers per load generator.

   From a memory perspective, the load generator machine has 8GB memory, of which 7GB is available for the Vusers, so approximately 87 Vusers per load generator machine (7GB / 80MB).

   Therefore, to meet both the CPU and memory capacity limits, you use the lower number of Vusers and calculate that for this business process, you can run approximately 56 Vusers per load generator.

## Configure runtime settings to improve load

To improve the ability to run more Vusers, in VuGen, select Replay > Runtime Settings > General > Replay, and check the Replay using recorded duration for steps option.

## Measure the load generator performance

Use the following monitors to ensure that the load generator is not being over-utilized.

Note: Over-utilization of the load generator can cause inaccurate transaction response time.

Monitor | Threshold
--- | ---
Processor\% Processor Time | 80%
Memory\Available Mbytes | Less than 10 percent of the total physical RAM
System\Context Switches/sec | Less than 8K context switches/sec per core

If you do not see standard performance issues, GDI resource consumption may limit the number of Vusers you can run. As the number of Vusers increases, the GDI resources needed to display the application in a browser can reach the limit supported by the Windows operating system per session.

You can better utilize the load generator hardware resources by connecting to the same load generator using different Windows sessions. For more details, see Terminal Services Manager.

## Manage TruClient scalability

Use the following tips to manage TruClient scalability:

- To support a larger number of Vusers, use high performance hardware and use more load generators.

- Increase the ramp up time between Vusers.

  For example, minimally set the ramp up to 2 Vusers every 30 seconds.

- Configure Controller to not initialize Vusers before they run. This will reduce the demand on the CPU and I/O during ramp up.

- If CPU is a bottleneck, consider doing one of the following:

  - Add a longer pacing time between iterations.
  - Add wait steps of a second or two.

- If memory is a bottleneck, run fewer Vusers.

- If the bottleneck is not CPU or memory, it is most likely the GDI resources. Consider using OpenText Professional Performance Engineering / OpenText Enterprise Performance Engineering integration with Terminal Services and split Vusers among different terminal sessions.

## Testing on different browsers

A script can be edited and replayed in any supported browser. To run the script in different browsers within the same load scenario, create a group for each browser and set the runtime settings value appropriately in each group. This enables comparison of Transaction Response Time (TRT) between browsers in the Analysis reports.

There may be cases where TruClient cannot detect or compensate for differences. For example, there may be differences in the application code depending on which browser is used.

## Known issues for TruClient scripts in load tests

You may encounter the following issues when running load tests with TruClient scripts.

- If you run a TruClient script in Controller, incorrect time measurements (0 in most cases) are displayed in the Analysis reports for Connection Time, DNS Time, Network Time, Server Time, and SSL per second.

- If you run a TruClient script in Controller, the Connections graph is always empty.

- When you view Web page component breakdown graphs for TruClient Vusers, TruClient measurements might not be available or might be less accurate than those of other protocols. For example the Time to First Buffer Breakdown graph, and measurements such as SSL Handshake, and Client/Error Time might not be available.

- TruClient is a UI-based protocol. Therefore, while running a TruClient script in Controller you might encounter an exception: "`Failed to Initialize. Reason TimeOut`". It is recommend to increase the Init time out. (Controller > Tools > Options) to provide the Vusers with additional time to finalize the initialization stage.

- If you encounter problems when running TruClient Browser Vusers in load tests, change the pacing in the script runtime settings.

  To change the pacing, open the script in VuGen, select Replay > Runtime Settings > General > Pacing, and then select either After the previous iteration ends or At <fixed/random> intervals.

## See also

- Performance metrics

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