1.

3 Configuring background processing

- IA Server has a configuration section for the background processing that can be tweaked to
fine-tune performance of the overall environment. Background processing consists of several
aspects, such as jobs, order items, batch items, and scheduled tasks. Using Spring profiles, it
is possible to disable specific categories of background processing overall, but it is also
possible to change the number of threads available for specific background processing.

- The defaults are ten threads for jobs, order items, and batch items, each for a total of 30
threads per IA Server instance. Many jobs spawn batch order items and, therefore,
effectively rely on all three thread pools simultaneously. Jobs frequently create multiple
order items that can be run either synchronously or asynchronously, depending on the job

- In turn, batch order items typically create multiple batch items, each of which can run in
parallel

- The related background configuration settings can be managed per individual IA Server and,
therefore, differ across instances.

- It requires trial and error to identify the optimal settings and may differ per environment.

- There are also different batch-related configuration settings with regards to individual batch
operation types that eventually control how many batches will be created per operation and,
therefore, how much parallelism can be accomplished.

- One should consider dedicating specific IA Server nodes for specific types of background
processing and disabling background processing entirely on others. It could be useful to
dedicate one or more nodes for REST processing, for example, while using others primarily
for background processing

- Especially with scaling loads and multiple jobs running in parallel, a single node deployment
may not be powerful enough to provide sufficient performance with default settings.

1.4 Moving content between stores

- Unstructured content in InfoArchive is stored in a storage system.
InfoArchive supports moving all or specific formats (eg:ci_container, ri_xml)
of unstructured content from one store to another.
- For example, if the unstructured content is stored in FileSystem store, the
Administrator can move the unstructured content to an Amazon S3 store
using the move-content command in IA Shell (refer to the command in the
InfoArchive Shell Guide for more information).
- To move unstructured content between stores, the following conditions
must be met:
• Content can only be moved between the stores of the same application.
• Source and target stores should be of REGULAR store types
 • Store status of the source store should be ONLINE or READ-ONLY, and the
target store should be ONLINE.

1.4.1 Compliance stores

- InfoArchive takes necessary precautions when moving content from/to WORM store
to maintain policy compliance. The following is done as part of the content move
from/to WORM stores

• It is not possible to move unstructured content from a WORM store non-

WORM store (except if the option DO_NOT_APPLY_STORAGE_RETENTION is
used).
• When the content is moved between WORM stores, the same retention
period gets applied to the moved content in the target store.

1.4.2 Offline stores

- Unstructured content in offline stores (for example, Amazon S3 Glacier) is not
available immediately to move to other stores. It requires a restoration process first
to bring the content online. As part of the move content, InfoArchive invokes the
restoration process when the content is offline. Once the content is available online,
then it will be moved to the target store

- InfoArchive provides necessary statistics on a number of moved content, offline

content and records failures in the background task logs. For the offline stores, the
Administrator needs to re-invoke the move-content command again once the
content is available online