Optimizing Web UI load testing for scalability

Scalability denotes the number of virtual users that can be emulated on an agent machine to generate load. In a Web UI load test, each virtual user requires one instance of a web browser to be run. Because each instance of a browser consumes key computer resources such as memory, CPU and Network data, you must tune a few of the parameters to comfortably run appropriate number of browser (virtual users) on an agent machine.

About this task

Here is the sample configuration of a computer that was used to determine the memory consumption:
Table 1. Sample configuration
Operating System Red Hat Enterprise Linux 6.6
System main memory 4 GB
Free memory before test run ~3 GB
Firefox (empty) memory consumption 130 MB
Firefox (medium-size app) main memory 200 MB
With this configuration, about 15-20 (300 MB / 200 MB) browser instances or virtual users can be emulated on on agent machine. Note, the browser memory consumption may vary based on the dom size of the web applications.

Tuning parameters

By default, the playback process of the Web UI test creates a thread pool of size 10 threads. This behavior affects the execution time when more than 10 virtual users per agent machine are emulated. This limit can be improved by passing the =-DrptDynamicThreads parameter to the agent machines.

Also, the Web UI test playback is a java process with maximum memory limit set to 512MB through the –Xmx argument. This parameter might yield more memory for browser instantiations.

Procedure

To optimize Web UI load test:

  1. In the Test Navigator view, double-click the location assets for optimization.
  2. In the General Properties tab, double-click RPT_VMARGS row. If RPT_VMARGS parameter is not available, click Add.
  3. In Property Name, specify RPT_VMARGS and in Property Value specify -DrptDynamicThreads -Xmx512m.
  4. Click OK and save the change.
Feedback