Configuring Caching for an Application
Caching is used to store run-time authentication and authorization rules, which can be expensive to calculate.
This page describes the cache that can be configured in each of the Crowd-connected applications, such as JIRA, Confluence and Bamboo. For an overview of the other types of caching offered by Crowd, please refer to Overview of Caching.
Crowd application caching is also referred to as 'client caching'.
On this page:
Explanation of Crowd Application Caching
Crowd-integrated applications can store user, group and role data in a local cache. This helps improve the performance of Crowd since these applications do not have to repeatedly request information from Crowd. Generally, it is not necessary to configure application caching, although this depends on the size of your application deployments.
Enabling Application Caching
To enable application caching,
- Edit the
crowd-ehcache.xml
file, which is located in theWEB-INF/classes
directory of your application's Crowd client. The two main properties are:- diskStore: If you have enabled disk persistence (
diskPersistent="true"
) this is the location on the file system where Ehcache will store its caching information. By default it usesjava.io.tmpdir
which is Java's default temporary file location. - defaultCache: This property has many configurable options. Please read the documentation provided by Ehcache to fully understand the implications and possibilities with this property. Some basic features are described below.
- diskStore: If you have enabled disk persistence (
Some applications may enable/disable caching based on the Crowd server setting
The Crowd API allows an application to query whether caching is enabled on the Crowd server (isCacheEnabled
). The Crowd Java client does not make use of this API feature, because it makes more sense to have application caching configured entirely on the application side. If you have a Crowd-integrated custom application which does make use of this API call, then the setting on the Crowd server will affect your application-side caching as well.
Extract from the ehcache.xml file
Below is a small snippet of the crowd-ehcache.xml
file.
<ehcache>
<diskStore path="java.io.tmpdir"/>
<defaultCache
maxElementsInMemory="4096"
eternal="false"
overflowToDisk="false"
timeToIdleSeconds="300"
timeToLiveSeconds="300"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"/>
</ehcache>
Basic Cache Attributes
- eternal: This indicates that all elements in the cache will live for ever and that any time-outs will be ignored. It is strongly recommended that you set this to false.
- timeToIdleSeconds: This sets the maximum amount of time between an element being accessed and its expiry. If you set this value to 0, the element will idle indefinitely.
- timeToLiveSeconds: This sets the maximum time between creation time of an element and its expiry. If you set this value to 0 it will live indefinitely.
- maxElementsInMemory: Sets the maximum number of elements that can be stored in the cache's memory. If this limit is reached, the default caching strategy LRU (Least Recently Used) will be invoked and those elements will be removed.
An element is anything stored in Crowd's cache: a user, a group, a list of users, a list of groups, a list of user memberships, a list of group memberships.
Hint: If you want to store everything in memory, try this value to start with:
(Number of users x 2) + (number of groups x 2)
Important Client Caches
The default maxElementsInMemory value of 4096 should be sufficient for most Crowd-integrated applications. However, for larger installations please ensure that the maxElementsInMemory matches the recommended size calculation listed below:
Name of Cache: | Size Calculation: |
---|---|
| The number of users in your system. |
| The number of groups in your system. |
| The number of groups in your system. |
| The number of users multiplied by the number of groups (users * groups). This total could be quite large, so you can optimize it by setting it to the number of users that are likely to be active at any one time. The algorithm will fall back to using the |
| The number of users in your system. |
| The number of groups in your system. |
RELATED TOPICS
- Backing Up and Restoring Data
- Browsing the audit log
- Configuring Server Settings
- Configuring the LDAP Connection Pool
- Configuring Trusted Proxy Servers
- Configuring your Mail Server
- Creating an Email Notification Template
- Logging and Profiling
- Overview of Caching
- Viewing Crowd's System Information