However, the Entries in Cache, Cache Hits and Hit Ratio are always 0.
Then I remembered there is a chapter in OpenDJ document - Entry Cache Settings.
OpenDJ implements an entry cache. The entry cache is not designed to cache every entry in your database, but is instead useful in cases where you have a few, typically large entries that are regularly used. For example, if you have a few large static groups and applications that regularly check group membership, you could cache your group entries.
Unlike Sun DSEE, OpenDJ is designed differently. It is not useful to enable the entry cache for user entries in OpenDJ in general. However, it is much more efficient to have a larger JVM and tune the database cache to make sure the whole database files are cached.
Read this chapter - Database Cache Settings.
Database cache size is, by default, set as a percentage of the JVM heap, using the backend property db-cache-percent. Alternatively, you use the backend property db-cache-size to set the size. If you set up multiple database backends, the total percent of JVM heap used must remain less than 100, and must leave space for other uses. Default settings work for servers with one user data backend JVM heaps up to 2 GB. For heaps larger than 2 GB, you can allocate a larger percentage of heap space to DB cache.
Depending on the size of your database, you have a choice to make about database cache settings. By caching the entire database in the JVM heap, you can get more deterministic response times and limit disk I/O. Yet, caching the whole DB can require a very large JVM, which you must pre-load on startup, and which can result in long garbage collections and a difficult-to-manage JVM. Test database pre-load on startup by setting the preload-time-limit for the backend.