Workers and Worker Threads
PureLoad 3.5 November 2007	http://www.minq.se support@minq.se

• 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
• 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 manager processes 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 manager processes 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 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. After the workers are created they will be displayed in the worker tree:

Note: Do not create too many workers on a specific manager since the system resources on the manager host might be exhausted. A general recommendation is to only use 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->Delete 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->Recreate 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 actual worker object in the worker tree. This output is referred as 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 amount of logging output is controlled by the Workers Logging setting in Tool Properties.

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. You can have scenarios assigned to several workers or vise versa by specifying several comma separated values on the Logical Name Parameter.

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 an 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 PureLoad Enterprise version.

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