Since jobs can be time consuming and performance demanding, the Application Server implements a queuing an load balancing mechanism for jobs. This allows to control the performance implication the execution of jobs has on the system.

Every job has an execution priority that may be any integer between 0 and  5 where 0 stands for the highest priority, 5 for the lowest, all priorities have alias names as listed in table 1. Not all priorities can be used by all users, see table 1 for details. All jobs are initially put to the job queue and therefore put into pending state i.e. they are not immediately executed but they wait for execution. The system decides which jobs are executed next based on the execution priority of the job. Jobs with higher priority are executed before jobs with lower priority. Among jobs with the same priority older jobs (jobs that have been in pending state for a longer time) are executed before newer jobs.

Table 1: Summary of job execution priorities

To limit the load implication the execution of jobs has on the system the Miscellaneous: Maximum concurrent job count can be configured as global setting. The default value for this setting is 16, the minimum value is 2, the maximum value is 128. Each executed job is executed on a separate thread and may therefore (according to hardware resources available, and according to the operating systems logic) be run on a separate processor.

Whenever a new job is created it is put onto the job queue and the system checks if there are already more than <%GS_MAXIMUMNUMBEROFCONCURRENTJOBS%> jobs running, if not it selects as many jobs on the job queue as possible and starts them. If no more jobs can be started the newly created jobs are left on the queue (and stay in pending state) for later execution. Whenever a running job finishes (and is put into  some archive state) the system checks the job queue again and will execute the oldest job with highest priority (if any). Jobs in state being paused/paused are included when counting the number of concurrently running jobs.

Note that due to the prioritization logic described above jobs with higher execution priority will always be handled first, even if the are newer jobs with lower execution priority. In rare cases this can lead to the situation that lower priority jobs are never executed if higher priority jobs are created frequently.

Additionally to the execution priority each job also has a thread scheduling priority that defines how the operating system prioritizes the thread started for a job. Threads in the operating system are scheduled to run based on their scheduling priority. Each thread in the system is assigned a scheduling priority. The operating system treats all threads with the same priority as equal. The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority.

If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread, and assigns a full time slice to the higher-priority thread, this is called a context switch in the operating system. You can assign the thread scheduling priorities listed in table 2 to jobs. Thread scheduling priorities are supported to optimize performance on installations a high load of jobs, in normal scenarios we recommend to leave the  thread scheduling priority untouched, i.e. in priority normal.

Table 1: Thread scheduling priorities supported by jobs.