This topic describes how to troubleshoot TruClient load issues .
TruClient technology provides you with the ability to quickly and easily record complex business processes. However, because TruClient records at the user level and requires a browser for replay, the more complex an application's client logic is, the more CPU and memory is required to run a Vuser.
Note: The TruClient footprint can be significantly larger than the footprints of other Vuser protocols. This larger footprint will require more CPU and memory capacity than would be required to run a similar business process recorded in another protocol.
Use the following method to determine the required number of load generators:
- Record a TruClient script.
Replay a single Vuser in Controller and check the average CPU and the peak memory consumption of the mdrv.exe process by adding a counter for % Processor Time and Private Bytes.
Based on your load generator hardware and the CPU and memory consumption of a single Vuser, calculate the number of Vusers per machine.
Example: Let us assume that each of our load generators has 8 core processors and 8GB of memory.
Let us also assume that a single Vuser consumes 80MB of peak memory and 10% CPU on average for the specific business process.
From a CPU perspective, if we limit the CPU consumption up to 70% utilization, we can have 7 Vusers per core processor (70% /10%). If our 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, we use the lower number of Vusers and we calculate that for this business process, we can run approximately 56 Vusers per load generator.
Configure Run-Time Settings to improve load
To improve the ability to run more Vusers, select Run-Time Settings> General > Replay and check the Replay using recorded duration for steps option.
Back to top
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.
|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 Overview in VuGen.Back to top
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 LoadRunner/Peformance Center integration with Terminal Services and split Vusers among different terminal sessions.
The following table provides estimated metrics regarding the browser footprint generated replaying an empty script. Use these values to estimate the hardware required for running a load test using TruClient. For details, see Calculate the number of load generators.
The metrics were compiled with the following specifications:
- Hardware specifications: 2.60 GHz CPU, 16 cores, 32 logical processors and 32 GB of memory.
- The script only contains a Wait step with a default wait time of three seconds.
- The pacing between iterations has been set to five seconds.
Monitor Firefox 40 Internet Explorer 11 Chromium 46 Single Vuser (empty script) Memory (private working set) ~80 MB 40 MB
~50 + ~30 + ~52 = ~132 MB
(sum of 3 processes)
Memory (private bytes) ~125 MB 45 MB
~67 + ~50 + ~58 = ~175 MB
(sum of 3 processes)
CPU ~2% ~2%
~3.5% + ~4.5% + ~8% = ~16%
(sum of 3 processes)
Context switches ~700 ~800 ~1300
Memory (private working set) ~3800 MB ~1700 MB
Memory (private bytes) ~6020 MB ~2000 MB
CPU ~80% ~80%
Context switches ~14000 ~190000 ~53000
Note: The Chromium footprint is larger than Firefox and IE. Therefore, you can run fewer Vusers with the same hardware.