Understanding the availability matrix
The availability matrix defines which types of events , and how many of their instances, the background task service is allowed to execute in parallel.
Executing background tasks consumes system resources, most importantly CPU time and system memory. Deciding which kind of tasks and how many instances of them are allowed to run in parallel on the same server is important because this will affect stability, throughput and overall system performance.
This decision is a trade-off: on the one hand, increasing the task parallelism can increase the throughput (more tasks are executed within the same amount of time), but on the other hand, it puts the system under pressure and may even result in situations when your process on the server runs out of memory.
The availability matrix is configured in the background task configuration, per server role, under the matrix element. The default background task configuration is located in \Websites\Author\EnterViaUI\Admin.XMLBackgroundTaskConfiguration.xml, which is delivered with the release and contains the latest suggested out-of-the-box values for the matrix. You can also find the contents of this file in Organize Space under .
Here is an example of a matrix section for a server role:
<matrix>
<group name="Translations" maxExecutions="2">
<handlers>
<add ref="CREATETRANSLATIONFROMREPORT" />
<add ref="CREATETRANSLATIONFROMLIST" />
<add ref="CREATETRANSLATION" />
<add ref="RELEASETRANSLATIONS" />
</handlers>
</group>
<group name="Export" maxExecutions="2">
<handlers>
<add ref="EXPORTFORPUBLICATION" />
<add ref="INBOXEXPORT" />
<add ref="REPORTEXPORT" />
<add ref="SEARCHEXPORT" />
<add ref="PUBLICATIONEXPORT" />
</handlers>
</group>
<group name="SynchronizeToLiveContent" maxExecutions="1">
<handlers>
<add ref="SYNCHRONIZETOLIVECONTENT" />
</handlers>
</group>
<group name="Others" maxExecutions="2">
<handlers>
<add ref="THUMBNAILSUBMIT" />
<add ref="ISHBATCHIMPORT" />
</handlers>
</group>
</matrix>
The matrix defines groups of handlers with common features, requirements or functionality. For every group, the maxExecutions attribute specifies how many instances of the specified background task handler can be executed concurrently. The availability matrix works proactively by controlling what the background task service will poll each time. Only tasks that are valid for the current state of execution and the availability matrix are allowed to begin executing.
Here is an example flow to better understand what happens when the service begins to execute.
Looking at the first group, Translations, the service will try to execute any background task with the configured handler, for exampleCREATETRANSLATIONFROMREPORT. While a CREATETRANSLATIONFROMREPORT instance is executing, the service is allowed to pick one more item from the queue matching the configured handlers of this specific group (including CREATETRANSLATIONFROMREPORT), for example, RELEASETRANSLATIONS. As long as both background tasks are executing, the service is not allowed to execute any more from this group because the limit 2, defined in maxExecutions attribute, is reached. Once one of the tasks has finished, the service is allowed once again to execute background tasks from the this group. The above reasoning is applied to every configured group and the service will always try to execute a background task from any group that still hasn't reached its maxExecutions limit.
The default background task configuration comes with two background task service roles, Default and Console. The Console background task service role is optimized for testing through the console mode. This role has only one group, containing all background tasks, and is configured to restrict the process to execute at most one background task at any given time.