Database preloading

The ability to maintain the database contents in the database cache within the Java Virtual Machine (JVM) memory is key to the PingDirectory server’s performance.

With a properly sized database cache, a priming method of preload directs the server to load the database contents into memory at server startup before accepting the first client connection. The time needed to preload the database is proportional to the database size. To avoid priming, you can start the server with the start-server --skipPrime command. If the priming method is none, or the --skipPrime option is specified at startup, the database cache slowly builds as entries are accessed. This can take several days to reach optimal performance.

The preload priming method is suitable for nearly all PingDirectory server deployments. If the size of the database precludes storing the whole database in memory, there are priming alternatives for optimizing server performance. This type of deployment is considered disk-bound since the disk is accessed when processing most operations. See the section Disk-Bound Deployments for more information. The remaining priming options are applicable to these environments.

The PingDirectory server database prime-method property configures how the caches get primed, what gets primed, such as data, internal nodes, system indexes, and where it gets primed, for example a database cache, file system cache, or both. The prime-method property is a multi-valued option that enables preloading the internal nodes into the database cache before the server starts and then primes the values in the background by cursoring across the database. For more details, see the PingDirectory Server Configuration Reference.

The following is a summary of the priming methods: