Understanding the availability matrix
The availability matrix defines which event types and how many of their instances is the background task service 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 compromise: increasing the task parallelism can increase the throughput (more tasks are executed within the same amount of time), but 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 matrix element. The default background task configuration is located in \Websites\Author\EnterViaUI\Admin.XMLBackgroundTaskConfiguration.xml, which is delivered on every CD, and contains the latest suggested out of box values for the matrix.
<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>
Matrix defines groups of handlers with common features or requirements or functionality. For every group, 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 finishes then 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.
Default background task configuration comes with 2 background task service roles. The Console background task service role is optimized for testing through the console mode. This role will restrict the process to execute a maximum of 1 background task at any given time.