Workers and Worker Threads
PureLoad 4.3 August 2011	http://www.pureload.com support@pureload.com

• General
  • Managers, Workers and Worker Threads
  • Worker Threads and Virtual Users
  • License restrictions
• Workers in the Console
  • Adding a Manager
  • Adding Workers and Worker Threads
  • Removing Managers, Worker and Worker Threads
  • Recreating Workers and Worker Threads
  • Worker Log
  • Thread Usage Over Time
• Advanced Worker Settings
  • Logical Name
  • Threading

General

Managers, Workers and Worker Threads

All machines that are going to generate load in a PureLoad session needs to be managed by a PureLoad Manager process. This process is responsible for all PureLoad activities on the machine. A manager can host one or several Worker processes. Normally only one worker process is needed on each physical machine.

Each worker process is responsible to maintain Worker Threads. The worker threads are the actual executors of scenarios. There is no built-in limit in PureLoad on the number of possible workers and worker threads that can be started. It is the license and characteristics of the actual hardware and OS that sets the limit.

Worker Threads and Virtual Users

In PureLoad one worker thread might correspond to one or more virtual users dependent on the scenario characteristics that is executed by the worker thread. For example if a scenario is designed to simulate how a user will access a web application, including wait times, then one worker thread will correspond to one virtual user.

License restrictions

When adding workers and worker threads in the worker tree the naming process will ensure that current license restrictions is not violated. A dialog will be displayed in case this happens.

Workers in the Console

When you are connected to naming you will see all registered managers in the Console. The name of each manager is the name of the host (or the IP Address) they are running on.

The following figure shows the worker tab with two managers with one worker each in the worker tree:

Selecting a manager node (or any node in the worker tree) will show node specific object properties in the panel to the right. The properties for a manager node shows various characteristics of the manager process such as host name, IP address, operating system and JVM properties.

Adding a Manager

Adding Workers and Worker Threads

Select one or more Managers or Workers, choose the Edit->Create Object menu option or the  button in the tool bar in order to create workers or worker threads. The following dialog is displayed when one or several manager objects are selected in the worker tree:

Specify number of Workers (normally one) and number of Worker Threads per worker to create. Logical names and threading model (described below under Advanced Worker Settings) can also be specified. After the workers are created they will be displayed in the worker tree. Depending on if the "Report Worker Thread Information" is selected in Tool Properties / Workers, threads will be displayed as nodes in the tree. The following shows the result if this property is true:

Note: Do not create too many workers on a specific manager since the system resources on the manager host might become exhausted. A general recommendation is to use only one worker and many threads.

Removing Managers, Worker and Worker Threads

To remove any object in the worker tree, select an object and choose Edit->Cut or the  button in the tool bar. If a manager is selected you will have to confirm if you want to remove the manager and/or only workers. If you remove a manager, the manager process will be stopped.

Recreating Workers and Worker Threads

The menu option Edit->Re-create Workers will force PureLoad to restart all current workers and worker threads. Normally there is no need for this, since workers are always recreated when a test is restarted, to make sure the state of workers is always the same.

Worker Log

Any output that is generated by a task during execution is handled by the worker process. The output from all threads running in a worker can be browsed by selecting the worker object in the worker tree. This output is referred to as the worker log. The contents is only updated when the Refresh button is pressed. The log contains the output generated from all threads in the worker:

It is also possible to save the log to a file by choosing the Save Log ... button.

The logging detail level is configured in the Tool Properties, Load Execution->Logging.

Thread Usage Over Time

Advanced Worker Settings

Logical Name

Logical name may be used to assign scenarios to specific workers.

To assign a specific scenario you set the same Logical Name for the scenario(s) as for the worker(s). This makes sure that the scenarios will only be executed by worker threads on the workers with the same logical name. Workers can have several names specified as a comma separated list of names, but scenarios are only allowed to have one name. The wildcard character * can be used as worker name to match any scenario.

For example, say that you have a scenario that is designed to be executed on one worker. We use a Logical Name "special1" for this scenario in the scenario editor:

and for a worker we also use the same logical name:

Now this worker will execute only the scenario with the same logical name.

Threading

By default one worker thread corresponds to one native OS thread. This means that there are OS/system dependent limits on how many worker threads tat can be created per worker. Most OS/systems allows for 1000 threads and modern Linux distributions up to 4-5000 threads.

But let us say that you want to simulate access from much more virtual clients, running  scenarios with low intensity (requests per second). One solution can be to use the alternative Threading Model: Multi. When using Multi threading one native thread will be used to serve several worker threads (as specified, using the Ratio parameter).

Note: Threading Model Multi is only available in the Enterprise Edition.

If you choose "Multi" you will see two new worker parameters:

Ratio

Specifies the ratio between number of native treads and worker treads. The default (100) means that if you create for example 10000 worker threads only 100 native threads will be used.

Delay

Specifies the random delay (in seconds) before the first scenario is executed. This setting is required to make sure each scenario is started with a "distribution" up to the delay specified, allowing the worker threads to start executing even if a lower amount of native threads exists.

A few notes regarding the use of Multi threading:

• Use this to simulate many clients having access to a server, not how many requests per second a server can handle (i.e how many multiple sessions can a server handle).
  
• Make sure your scenario has long delays built in, using RandomSleepTask or SleepTask.