Configure and tune caches
This topic introduces how to configure PPM caches, and provides some tips for cache tuning.
This section describes the steps to configure cache settings.
To configure cache settings:
- Navigate to the <PPM_HOME>/conf directory.
Locate the custom_cache.conf.example file in the directory and make a copy of it. Rename the copied file custom_cache.conf.
Caution: It is strongly recommended not to make any modifications to the cache.conf file. Overwriting the cache.conf file with an earlier version would make the server fail to start.
- Open the custom_cache.conf file and modify the values of the cache parameters according to your needs.
Restart the PPM server.
Note: To apply the cache settings without restarting PPM, you can set the suppress-conf-reload parameter in the custom_cache.conf file to false. However, it is recommended to limit this action to the development environment or for the purpose of cache tuning exclusively.
Tuning PPM Cache performance should be done at the same time as tuning PPM JVM heap size. This means to find the right balance between the following:
JVM heap size. If JVM heap size is too large, full garbage collection periods will be too long and the application might become unresponsive for seconds, degrading users experience.
Cache size. A larger cache size means more cacheable objects, a better hit rate, and fewer objects to reload from the database, which result in better application performance. However, if cached objects end up taking too much memory, the performance of the application degrades and might even cause out-of-memory problems for the legacy cache.
Recommended practices for tuning PPM cache
We recommend the following practices for PPM cache tuning. These practices may end up conflicting with each other. If that happens, use your best judgment.
|When to use
|Increase the cache size
|Increase the JVM heap
|If you see some “soft reference reclaimed” flushes
|Reduce the heap size
|If you notice long full garbage collection time (many seconds) during which the system is unresponsive
|Tune JVM garbage collection
If you notice long full garbage collection time (many seconds) during which the system is unresponsive
Note: You need to use a JVM monitoring tool in order to ensure that JVM pauses are caused by full garbage collection.
Additional tips for tuning PPM cache
The following table lists additional tips for PPM cache tuning:
|Try different configurations
|There is no “standard” cache configuration. Measure, tune, flush, and repeat until you reach satisfactory numbers. All PPM usages are different, and as a result cache configurations should be tuned accordingly.
|Capture peak load statistics
|When tuning the PPM cache, try to do so after capturing statistics during the highest peak load time (usually happening on Friday afternoon or Monday morning). Tuning cache only makes sense if it is done to properly handle peak load usage.
|Avoid automated cache flushing unless necessary
|Try not to flush the caches (using
ksc_flush_cache) in an automated way unless you really have to. If you use
kRunCacheManager, NEVER use the “A” option to flush all caches in an automated script. You should not flush more caches than necessary.
If memory limit does not allow you to set the proper max cache size for all the entities, you can rank the caches by the value “Average Load time” x “Misses”, and first increase the cache size of the cache(s) with the highest value. They are the caches most likely to have a measurable performance impact.
|Tune cache differently based on node types
|You might want to tune differently the PPM nodes in your cluster depending on whether they are Service nodes or Web User only nodes. The entities loaded (and thus the optimal cache settings) are different. For example, a pure Service node will never load portlets or menus, but might need a larger cache size for fiscal periods.
Tips when using kRunCacheManager.sh
|Don’t forget that when you use kRunCacheManager.sh, it will always flush selected caches on all nodes of your PPM cluster, but it will reset caches statistics and force garbage collection only on the node it is connected to.
About MLU environments
In the environments where more than one language is installed on PPM, if a same object is loaded by different users using different languages, the object will be stored in the cache once for each of the different languages used. Your cache should be set accordingly.
For example, on a system with 3 languages installed for PPM, if you have 20 request types, you should set the maxSize value for the request types cache to 60, i.e. 20 (request types) times 3 (languages). However, if you have 1000 users, you might still set the users cache maxSize value to 1000, since a given user will usually always log in PPM using the same language; so each user object will be loaded in the cache most often once, using the language of the user.