Worker Queues, Workers and ThreadsLast Updated: 03/30/2016 Introduced in Verision: 3.2 |
Decisions supports “Work Queues” which represents physical threads that can be used for multi-threaded processing.
Background Work:
Scheduled Jobs.
Workflows that are running in the Async mode.
Work Queues: Worker count and Queue count do not have to match.
Work Queue Workers are stored and can be configured in the System > Jobs And Events > Work Queue Workers Folder in the Portal.
Work Queue Worker has following configurations:
Cluster: Multiple Servers are aware of one another.
In the Cluster, servers must know about one another. This allows the data that is cached to be kept in sync.
When Data is cached on Server 2, it notifies Server 1 and Server 3 that the data must be refetched next time it is needed.
Example: Flow Edited.
Load Balanced for Users:
A load balancer can direct user to any of the servers in the cluster to interact with the Portal.
Background Processing in the Cluster:
Queues:
Queues are defined for all servers in the Cluster.
Each Server can identify Queues it will work on.
Worker Profiles:
How frequently will this server check for work that needs to be done when work is being done?
How frequently will this server check for work that needs to be done when this server’s workers have been idle?
How ‘new’ should the items in the queue be that this server takes them from the queue?
Means: If Server A is the main worker, but very busy on the job. Server B can be configured to check infrequently and when it sees the job over 30 minutes in the queue, it can start to work on it.
Common Example:
In this Example Server 1 and 2 are user portal servers behind a load balancer. Server 3 is the main worker.
Server 1:
Has 3 worker threads.
Checks every 10 minutes.
Only works on Jobs that are over 30 minutes old.
Server 2:
Has 3 worker threads.
Checks every 10 minutes.
Only works on Jobs that are over 30 minutes old.
Server 3:
Checks for work every 5 seconds.
Runs 8 worker threads.
