Key to Directory Server performance is the ability to maintain the database contents in the database cache within the JVM memory. 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, the server can be started with the start-server --skipPrime command. If the priming method is none or the --skipPrime option is specified at startup, the database cache will slowly build as entries are accessed. This could take several days to reach optimal performance.
The "preload" priming method is suitable for nearly all Directory 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 Directory Server database prime-method property configures how the caches get primed, what gets primed (data, internal nodes, system indexes) and where it gets primed (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.
- Preload All Data. Prime the contents of the backend into the database cache.
- Preload Internal Nodes Only. Prime only internal database structure information into the database cache, but do not prime any actual data. (This corresponds to the cache-keys-only cache-mode.)
- Cursor Across Indexes. Use the cursor-across-indexes property to iterate through backend contents. This is similar to (and may be slower than) using the preload mechanism, but it enables priming to happen in the background after the server has started. This is used when shorter start up times are desired, and the slower performance of an uncached database is acceptable until the database is primed.