Fine tune the Scheduler example

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > System maintenance and monitoring > Environment settings and administration > Management Console > Scheduled jobs administration > How to fine tune the Bizagi Scheduler >

Fine tune the Scheduler example

Scheduler scaling example

For the sake of example, we have defined a scenario with the following characteristics:

 

75% of the tasks are service tasks configured as asynchronous activities.

The case creation rate is one case per hour.

Each case has on average 25 asynchronous activities executed in parallel.

 

First Scenario: Optimum performance

Due to the high demand of asynchronous activities, the ASYNCWORKITEM table is queried constantly to review pending tasks from the Scheduler. With the following results:

 

Scheduler_01

 

This scenario shows that there is no increment in pending tasks, nor a CPU usage greater than 60%, therefore, you do not need to fine-tune or scale-out.

 

Second Scenario: Fine-tuning the Scheduler

In a second scenario, the system is monitored with the following results:

 

Scheduler_02

 

There is evidence that the number of pending tasks to be executed by the Scheduler is becoming greater, and is increasing over time, meaning that the Scheduler es queuing tasks. Nevertheless, the CPU usage remains on average under 60%, therefore, you can fine-tune the Scheduler to avoid having a cumulative queue of pending tasks.

 

To tune this you can increase the number of threads for asynchronous activities. You can adjust the MaxThreadsForAsynchWorkItems.

 

After the parameter is tuned, the number of pending tasks starts to become lower to reach zero pending tasks.

 

note_pin

You need to assess if the load of the Scheduler is due to Asynchronous tasks, custom jobs, or another type of job. You need to compare the number of pending tasks from the ASYNCHWORKITEM table and the JOB table. Depending on this, you can either increase the threads for asynchronous items (MaxThreadsForAsynchWorkItems) or for another type of job (MaxThreadsForJobs or MaxThreadsForCustomJobs).

 

Third Scenario: Scaling-out the server

In the third scenario the system is monitored during the same times with the following results:

 

Scheduler_03

 

The pending tasks are still being queued because there is an increasing trend on the pending tasks (blue bars). But, in this scenario the CPU usage average is around 80%, above the suggested limit of  60%. These metrics show that the system is overloaded and the CPU resources are not enough to handle all the Scheduler requests.

 

In this scenario, you need to evaluate first if it is possible to scale-out the number of logical processors of your CPU. If yes, you can increase the number of cores or logic processors, and then look to fine-tune the Scheduler by increasing the threads for asynchronous tasks, like the second scenario.

 

If scaling-out the logic processors in the same server is not possible, you can look to scale-out your infrastructure with and additional Scheduler instance. Our recommendation is to keep a maximum of two Schedulers per server. However, this depends on your hardware performance, and if you have more software under the same server.

 

Scheduler_04