How Preload Works

Preload is initiated as soon as the first server in the cluster starts. If there are more than one servers in the cluster, one of the servers initiates the preload.

The preload is split up in multiple portions and initiated in parallel. The parallelism is controlled by pool size of AsyncCall queue on each server.

When the preload is running, you can use the application. However, as preload is quite resource intensive, services may experience increased response time.

You must first need to configure the number and type of objects that are to be preloaded based on available memory for cache. If memory is insufficient, loaded objects are evicted and preload is ineffective.

Preload initiates the loads of various objects in parallel and attempts to use all available resources across the cluster as follows:

  • Load each object in a separate thread
    • Start loading of RECORD, PRODUCTKEY, RECORDMAXMODVERSION, SYNCLOG, and SYNCRECORD in separate threads. Split object loading by each repository. For example, if you have 10 repositories, start loading the data for PRODUCTKEY in 10 threads.
    • Split each repository and load each tranche or part in a separate thread. For more information, refer to Preload of Large Data Using Tranche.
  • Collect data in cache using a separate thread. For more information, refer to Configuring the Cache to Replicate the Data.