In the preceding chapter we described the specific values we modified for
the IBM® WebSphere® Portal caches in our environments. This chapter
describes the WebSphere Portal caches, the general parameters for those caches,
which cache instances WebSphere Portal v6.1 provides, and, finally, some sample
portal usage patterns along with suggestions on portal cache properties.
Contents
General Information
Cache Configuration Properties
Cache Usage Patterns
Cache Instances
Access Control
Portal User Management
Datastore
Model
URL
Mappings
Virtual Portals
WSRP
Dynamic Assembly/Process Integration
Policy
Collaboration
Services
Miscellaneous
Example Scenarios
With WebSphere Portal V6.1, portal configuration properties, including
cache configuration properties, are managed through the WebSphere Application
Server Administration Console. In previous WebSphere Portal releases these
configuration properties were maintained in properties files. More information
on how to modify portal configuration properties can be found in the Setting
configuration properties section of the WebSphere Portal Version 6.1
information center.
Cache Configuration Properties
The cache configuration properties are organized in two groups: global
configuration properties and cache instance specific properties. Global
properties have the prefix cacheglobal and apply to all caches unless they are
specifically overridden with a cache instance specific property. Cache instance
specific properties have the prefix cacheinstance and then contain the name of
the cache instance and the name of the property, for example:
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP.size
All entries of a cache are governed by a single set of properties.
The cache configuration properties that are safe to modify are:
enabled, lifetime, size, shared,
replacement, and admit-threshold. The replacement
and admit-threshold properties do not apply to all cache
implementations. In general, only caches that are not shared will use these
properties. There are other properties that should not be modified unless
specifically instructed to do so by IBM WebSphere Portal support.
enabled: The enabled property determines whether a cache
is used or not. If a cache is not enabled, the property has a value of
false, then no values are held by the cache and every cache lookup
will return a null value. This property should only be modified for testing
purposes, never in a production environment. The supported values are
true and false and the global default value is
true.
lifetime: The lifetime property determines the number of
seconds an entry will exist in a cache. A cache no longer returns an entry once
the entry has existed longer than the lifetime property. Cache entries
can also be invalidated prior to reaching their lifetime due to explicit
invalidation of the entry or Least Recently Used (LRU) eviction from the
cache.
A value of -1 indicates an infinite lifetime. This value should be
used with caution since cache entries will only be invalidated
programmatically. Infinite lifetimes are particularly discouraged with access
control caches for the following reasons:
- In a cluster there can be rare occurrences when not all cache
invalidation messages are processed on every node due to race conditions in the
application server’s dynacache code. While the probability of this occurring is
low, it can not be completely avoided with the current code base. Finite
lifetimes allow these entries to be invalidated.
- Finite lifetimes allow modifications made to roles, which have been
externalized to an External Security Manager, to be reflected in role
caches.
If updates to production environments are restricted to a well-defined staging
process using XML Access, it is usually safe to use infinite lifetimes.
size: The maximum number of entries in a cache is limited by the size
property. If this size limit is reached, entries are removed from the cache by
an algorithm which usually includes 1) remove invalidated entries and entries
which have exceeded their lifetime and 2) apply a LRU algorithm to the valid
entries.
Any positive integer is allowed. Cache sizes have a direct impact on the memory
requirements of your portal, specifically the demands on the Java™ heap.
You should monitor and record the Java heap metrics and any performance impact
when modifying the size of a cache.
shared: Cluster-aware caches are shared across the nodes
of a cluster. These caches propagate invalidations of cache entries by using
the WebSphere Application Server DistributedMap interface.
Supported values are true and false. The default values
shipped in WebSphere Portal V6.1 should apply to most configurations. If you do
not have a cluster there may be a small performance benefit to setting this
property to false since a different cache implementation is used. We
did not modify the defaults in our single node measurement environments.
If this parameter is false in a cluster, it can ultimately lead to
data inconsistencies between the cluster members.
replacement: The cache replacement algorithm used by these caches
works on the frequency of recent access to cache entries; entries that have
been used frequently are less likely to be discarded than entries that have not
been used frequently. This parameter controls how long the access history will
be kept. A setting of aggressive means those only recently accessed
entries will be considered, which causes stale entries to be discarded more
quickly. The opposite setting, conservative, will consider a longer
access history. The intermediate setting of moderate is appropriate
for most caches.
admit-threshold: Caches that have a very high insert rate may cause
useful entries to be discarded prematurely. An admittance threshold restricts
the rate at which entries are allowed into the cache by only allowing them to
enter after an attempt has been made to insert the same entry into the cache
multiple times. The default value of 0 means no admittance
threshold, which will allow entries into the cache on the first insert
attempt. This is appropriate for most caches. A higher value indicates that a
cache entry will not be allowed into the cache until that many attempts have
been made to insert the same key. For example, a value of 2 means that
the first two attempts to insert a cache entry will be ignored, and the third
attempt will insert the value into the cache. We did not modify the
admit-threshold for any cache in our measurement environments.
Most WebSphere Portal caches follow the simple paradigm: if an entry
already exists use it, otherwise add the entry. However, there are caches that
behave differently. Each cache follows one of the following four patterns:
- Pattern: regular
The regular pattern, described
earlier, is the most common cache pattern:
value = cache.get(key);
if (value == null) {
value = calculateNewValue();
cache.put(key, value);
}
- Pattern: invalidation checking
Invalidating cache entries in a clustered environment is rather expensive.
Therefore, portal caches often check whether the entry to be invalidated
actually exists in the local cache.
test = cache.get(key);
if (test != null) {
cache.invalidate(key);
}
Caches following this pattern follow the regular pattern for
all but invalidation actions.
- Pattern: multiple object types
Most caches hold only
a single object type. When caches can hold multiple types, they follow the
regular pattern for each of those types.
- Pattern: cascading object types
This pattern is a
special case of the ‘multiple object types’ pattern in that two or more object
types that are queried in a certain order are stored in a single cache. There
may be one cache hit along with a cache miss on a regular basis.
value = cache.get(keyA);
if (value == null) {
value = cache.get(keyB);
if (value == null) {
value = calculateNewValue();
cache.put(keyA || keyB, value) // either
key could be used
}
}
This section describes the caches in WebSphere Portal V6.1 along with
hints to best configure those caches. As you saw in the modifications we made
in our measurement environments, the size and lifetime
properties are the most commonly modified properties when tuning portal caches.
You may wish to increase the size of a cache if many values are used on a
regular basis and there is sufficient space available in the Java heap. You may
wish to increase the lifetime of the entries of a cache if the cached data
rarely, if ever, changes and it is not critical to your business to reflect
changes immediately in your portal.
Each cache description includes the following attributes:
- Default size, default lifetime and cache usage
pattern.
- Cache content and scaling factor (i.e. factors that cause the cache to
increase).
- Information on the read and write access to the cache.
- Approximate costs for re-creating cache entries and relative size of
cached objects. Small objects range from 16 to 300 bytes and the largest cache
entries are not larger than a few thousand bytes. One known exception are
access control caches in systems with many resources per user can hold entries
that are very large, beyond 50,000 bytes, to reflect all the resources which a
user can access.
- Some cache descriptions include a sample scenario with suggested property
values.
ACCESS CONTROL1
This section describes each of the access control caches. It is
critical for proper operation of a portal that the access control information
be current. For this reason it is vital that these caches be shared within a
cluster so that the information is propagated to all members of the cluster.
Different lifetime values should be chosen to avoid concurrent reload of
information from multiple caches. This pattern of rather random lifetime and
invalidation intervals could also be applied to other caches.
The access control caches are divided into two groups: those caches (the
first caches in the list) used during all access control operations in all
portal setups and those caches (starting with the cache
com.ibm.wps.ac.ApplicationRoleOIDCache) used for the WebSphere Portal Composite
Application Infrastructure.
1 This section is partially taken from the following whitepaper:
Portal Access Control Performance Tuning available at: http://www-
128.ibm.com/developerworks/websphere/library/techarticles/0508_buehler/0508_bueh
ler.html
Figure 1 shows the relationships among the various caches. The small
cylinders represent cache instances. The green caches are caches of the portal
user management (PUMA) component that are closely related to the caches of the
portal access control component. The PUMA caches contain information
originating from the user registry. Portal access control uses these caches for
user identification and group membership retrieval.
The vertical axis represents the cache aggregation direction. The cache
instances in layer N leverage cache instances of lower layers to compute their
values. For example, when computing effective permissions (entitlements) for a
user (cached in the ExplicitEntitlementsCache), the portal access control
component leverages existing cache values from the ChildResourcesCache and
RoleMappingCache.
Figure 1. Portal Access Control Cache Hierarchy
com.ibm.wps.ac.PermissionCollectionCache
Default size: 2000, default lifetime: 10240, usage pattern: regular
(admit-threshold).
This cache contains permission collections that can be used for permission
checks. It scales with the number of permissions in the system, i.e. the number
of portal resources and permissions assigned on those. Entries in the cache
typically are requested very frequently during permission checks. An
admit-threshold is used to avoid caching rarely used permissions. You may wish
to try different admit-threshold settings to tune this cache. Entries are never
invalidated from the cache. Creating a cache entry is very fast since all
required information is in-memory. A cache entry is small.
com.ibm.wps.ac.AccessControlUserContextCache
Default size: 8000, default lifetime: 1200, usage pattern: regular.
This cache contains the access control user context objects, a local cache for
permissions assigned to a specific user. If possible all requests against
access control are answered using this information so that access control
methods can return very quickly. This cache scales with the number of active
users. For fast portal operation, you should make sure that the entries for all
actively working users fit into the cache, especially if a user has access to
many portal resources. Entries are invalidated from the cache upon any portal
administrative action. Creating a cache entry typically is rather cheap because
most information is in-memory, but can take a while if the required information
cannot be found in other caches. An entry in the cache can be become very
large, depending on the number of resources the user can access.
com.ibm.wps.ac.ProtectedResourceCache
Default size: 5000, default lifetime: 10143, usage pattern: regular.
This cache contains the resources protected by portal access control. The size
of this cache scales with the number of protected resources accessed by the
active users in the system. Entries are read from the cache during every
permission call or entitlements call against access control. Entries are
invalidated from this cache during resource deletion, resource relocation,
modification of the resource state (private/shared), modification of the
resource owner, externalization, internalization, and role block change.
Creating a cache entry requires a single-row lookup in the portal database. An
entry in the cache is relatively small.
com.ibm.wps.ac.OwnedResourcesCache
Default size: 5000, default lifetime: 10043, usage pattern: invalidation
checking.
This cache maps resource owners (user groups or individual users) to the
resources they own. This cache scales with the number of active users/groups
multiplied with the different ResourceTypes they access. There is one entry in
the cache per principal per resource type per WebSphere Portal domain. Data is
read from this cache during many portal access control requests, if the
corresponding entitlements are not already cached in an entitlements cache.
Entries are invalidated from this cache during resource deletion, modification
of the resource owner, externalization, and logout of the user. Creating a
cache entry means executing a multi-row query against the portal database. An
entry in the cache is relatively small.
com.ibm.wps.ac.RolesCache
Default size: 10000, default lifetime: 3630, usage pattern: invalidation
checking.
This cache contains the role instances. The size of this cache scales with the
number of active users/groups multiplied by the different ResourceTypes they
access. There is one entry per role instance per principal per resource type
per WebSphere Portal domain. Data is read from the cache during many portal
access control requests, if the corresponding entitlements are not already
cached. Entries are invalidated from this cache during role mapping creation,
role mapping deletion, resource deletion, externalization, internalization, and
logout of the user. Creating a cache entry means executing at least one, but
potentially multiple database queries. An entry in the cache is relatively
small.
com.ibm.wps.ac.ExplicitEntitlementsCache.* and
com.ibm.wps.ac.ChildEntitlementsCache
Default size: 10000, default lifetime: varying (around 10000), usage pattern:
invalidation checking.
These caches contain the permissions of a user or group on a number of
resources of the same ResourceType. There are dedicated caches for the
different ResourceTypes. For example, the cache for pages is called
com.ibm.wps.ac.ExplicitEntitlementsCache.CONTENT_NODE. All
ResourceTypes that are not specified explicitly will be cached in the default
cache. The size of this cache scales with the number of active users/groups
multiplied by the different ResourceTypes valid for this cache and accessed by
the users and groups, either by ‘using’ the resource during navigating the
portal or by portal administration. There is one entry per set of permissions
per WebSphere Portal domain. Entries are read during ‘regular’ access control
requests, during page rendering and, especially, during portal administration.
If a certain resource type is not used, you will see only misses and no other
activity on the corresponding cache. Entries are invalidated from this cache
during all access control modifications and logins. Creating an entry in one of
these caches typically can be done from in-memory information in the
lower-level caches. If the required information is not available multiple
database requests might be required to create a cache entry. An entry into the
cache is rather small, but built of multiple objects typically stored in other
caches.
com.ibm.wps.ac.ExternalOIDCache
Default size: 10000, default lifetime: 8640, usage pattern: regular.
This cache contains the mapping between the external ObjectIDs of individual
protected resources, for example page or portlet IDs, and the portal access
control specific ObjectIDs stored in the database table PROT_RES. Entries are
read from the cache during many portal access control requests. The size of
this cache scales with the number of protected resources accessed by the active
users in the system. Since this mapping is immutable, this cache is never
explicitly invalidated. Creating a cache entry requires a single row database
query. An entry in the cache is fairly small.
com.ibm.wps.ac.groupmanagement.NestedGroupCache /
com.ibm.wps.ac.groupmanagement.GroupCache
Default size: 1000, default lifetime: 3600, usage pattern: regular.
Only one of these two caches is used in a WebSphere Portal installation
depending on your ‘nested groups’ setting. If nested groups are supported, the
NestedGroupCache cache will be used, otherwise the GroupCache is used. The
caches contain the nested or direct groups to which a user belongs. The size of
this cache scales with the number of active users and the number of virtual
portals they access. The cache is accessed during login into portal, but
typically not during regular portal navigation. Its main use case is during
administration of users and user groups. Entries are invalidated from this
cache during login of the user and after user and group administrative changes.
Creating a new cache entry requires queries against the WMM component and then
typically against the user repository. An entry in the cache is
medium-sized.
com.ibm.wps.ac.ChildResourcesCache
Default size: 1000, default lifetime: 7200, usage pattern: regular.
This cache contains the resource hierarchy within portal access control. The
size of this cache scales with the number of protected resources accessed by
the active users in the system, like the protected resources cache. This cache
does not contain leaf objects in the access control tree, so the number of
entries typically is smaller. The cache is accessed during most portal access
control requests. Entries are invalidated from this cache during resource
deletion, parent change of the resource, modification of the resource owner,
externalization, internalization, and role block change. Creating a cache entry
includes a multi-row query against the portal database. An entry in the cache
is fairly small.
com.ibm.wps.ac.ApplicationRoleOIDCache
Default size: 5000, default lifetime: 7650, usage pattern: regular.
This cache maps application role names to the corresponding object IDs. It
scales with the number of application roles defined in the system. Data is read
from the cache frequently when accessing or administering composite
applications. In all other situations the cache is basically not used at all.
Entries are invalidated when application roles are deleted. There is one entry
in the cache per application role per WebSphere Portal domain, except for the
customization domain. Creating a cache entry means reading a single row of data
from the portal database. A cache entry is fairly small.
com.ibm.wps.ac.ApplicationRoleDescriptorCache
Default size: 5000, default lifetime: 8450, usage pattern: regular.
This cache maps the object ID of an application role to its corresponding
descriptor object, which contains the application name, parent application and
other information. The cache scales with the number of application roles
defined in the system. Data is read from the cache frequently when accessing or
administering composite applications. In all other situations the cache is
basically not used at all. Creating a cache entry means reading a single row of
data from the portal database. A cache entry is medium-sized.
com.ibm.wps.ac.ApplicationRolesForPrincipalCache
Default size: 5000, default lifetime: 8760, usage pattern: regular.
This cache maps the available application roles to a portal user. It scales
with the number of active users in the system. Data is read from the cache
frequently when accessing or administering composite applications. In addition
this cache is also used as a lookup for application role information even if no
application roles are used. Hence you will see frequent read access on this
cache under all circumstances. Creating a cache entry is rather expensive. It
involves three multi-row queries against three WebSphere Portal domains. A
cache entry is medium-sized.
com.ibm.wps.ac.ContainedRolesCache
Default size: 5000, default lifetime: 8650, usage pattern: regular.
This cache contains the mappings between application roles and the ‘regular’
roles defined in them. The cache scales with the number of application roles in
the system. There is one entry for every WebSphere Portal domain. Data is read
from the cache frequently when accessing or administering composite
applications. In all other situations the cache is basically not used at all.
Creating a cache entry is rather expensive. It involves two multi-row queries.
A cache entry is medium-sized.
com.ibm.wps.ac.ApplicationRoleChildrenCache
Default size: 5000, default lifetime: 8760, usage pattern: regular.
This cache is not used in WebSphere Portal V6.0.
com.ibm.wps.ac.ParentResourceRoleMappingCache and
com.ibm.wps.ac.ResourceRoleMappingCache
Default size: 1000, default lifetime: infinite, usage pattern: regular.
These two caches are used for special access control scenarios and typically
are not accessed during portal processing. Settings of these caches should not
be modified.
PORTAL USER MANAGEMENT
The following caches are used by the portal user management component
(PUMA). In so far they are closely related to the access control caches and
caching within VMM.
com.ibm.wps.puma.DN_OID_Cache /
com.ibm.wps.puma.OID_DN_Cache
Default size: 1500, default lifetime: infinite, usage pattern: regular.
These two caches contain the mapping between the distinguished name of users
and groups and their internal ObjectID identifier. The size of these caches
scales with the number of active users and groups or users and groups that are
used for delegation. Entries are invalidated from this cache during deletion of
a user or group. Creating an entry requires one database lookup. An entry into
the caches is fairly small.
DATASTORE
The datastore caches contain data read from the portal database. It is not
the goal of these caches to be a complete image of the DB content, but to have
frequently-accessed but raw information available for all other portal
components to use.
com.ibm.wps.datastore.services.Identification.OidAndUniqueName.cache
Default size: 5000, default lifetime: infinite, usage pattern: regular.
This cache stores unique names. It is used quite frequently during page
rendering and especially administration of unique names. Page and portlet
unique names make up the biggest part of the cache content. The cache should be
large enough to hold entries for the most frequently used pages and portlets
having a unique name associated with them. Note that not all resources have a
unique name associated with them. To eliminate database lookups the cache size
could correspond to the database table UNIQUE_NAME multiplied by two, to allow
for mapping in two directions. Creating a cache entry involves reading one
entry from the portal database. An entry object into the cache is fairly
small.
com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache maps long Virtual Portal object IDs to the corresponding portal
internal short ID. It scales with the number of virtual portals in the system,
plus one additional entry. It is used heavily only if more than one virtual
portal exists in the system. Data is read from the cache during every rendering
request then. For optimal caching the size should be set to the number of
Virtual Portals defined in the system. Creating a cache entry involves one
single-row database lookup. An entry object into the cache is fairly
small.
com.ibm.wps.datastore.PortalIdCache.explicitLpidPerVP
Default size: 100, default lifetime: infinite, usage pattern: regular.
This cache maps the short object ID for a virtual portal to the corresponding
long ID. In comparison to cache
com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache it stores the reverse
mappings. Hence all other descriptions given above also apply here.
com.ibm.wps.datastore.pageinstance.OIDCache
Default size: 3000, default lifetime: infinite, usage pattern: regular.
This cache stores information on portal pages for fast retrieval during login
or page navigation. It scales with the number of page instances in the system.
It is one of the most frequently used caches and should be large enough to hold
all pages that are frequently accessed by users. Pages are loaded and put into
the cache by direct navigation, creating a link to another page or by working
with the page during portal administration (always including all higher
derivation levels). Creating a cache entry includes one single-row database
lookup. An entry to the cache is medium sized. To achieve best performance, in
terms of cache hit rate, the size should be set to a value so that all pages
defined in the system fit into the cache. This corresponds to the row count of
the following database table: PAGE_INST.
com.ibm.wps.datastore.pageinstance.DerivationCache
Default size: 3000, default lifetime: infinite, usage pattern: regular.
This cache stores the mappings between pages and their derivation children, or
empty mappings if no such children exist. Like the pageinstance.OIDCache
cache this one also is accessed very frequently during page rendering
and administration. Creating a cache entry involves one multi-row database
query. This cache also scales with the number of pages in the system. Hence,
you can use the same sizes for the previous cache and this one. In most portal
usage scenarios the actual size of this cache will be somewhat lower than with
the page instance cache. An average entry in the cache is rather small. Only if
all your pages have long lists of derivation children will the entries become
larger. To achieve best performance, in terms of cache hit rate, the size
should be set to a value so that all pages defined in the system fit into the
cache. This corresponds to the row count of the following database table:
PAGE_INST.
com.ibm.wps.datastore.pageinstance.DynamicNodeCache
Default size: 5, default lifetime: infinite, usage pattern: regular.
This cache stores one list per domain. These lists contain all pages in the
corresponding domain that are flagged as dynamic nodes, i.e. dynamic assembly
content nodes can be added below these pages. Since the number of domains does
not grow, the size as well as other properties of this cache should not be
modified. The size of one entry into the cache ranges from small in a portal
with very few dynamic nodes up to medium with many dynamic nodes in the
system.
com.ibm.wps.datastore.services.Identification.SerializedOidString.cach
e
Default size: 2500, default lifetime: infinite, usage pattern: cascading object
types.
This cache stores serialized ObjectIDs used in request parameters or XML Access
files. It contains a subset of all the loaded ObjectIDs in memory. In so far it
scales with the number of ObjectIDs in the system, but not for all of these IDs
the serialized version is requested, hence the actual size is impossible to
predict. The cache is used during every request. Creating a cache entry is
rather cheap. Typically all information can be retrieved in memory, database
lookups are scarcely necessary. A cache entry is fairly small.
MODEL
The model caches can be categorized into two groups: One group of
caches is accessed during every portal request during page rendering. The
second group of caches is especially important for administrative actions.
Hence those caches are especially important in those environments where content
and portal administration is done. Most run-time caches have the name suffix
live; the administrative caches have the suffix isolated.
Figure 2 describes the hierarchy of caches in the model component and
depending portal components. The structure of the picture is identical to
Figure 1 in that the vertical axis shows caches with increasing aggregation of
data. The model component only caches data at a rather high aggregation level.
All data cached here hence is rather valuable, reloads can be expensive if the
corresponding data is not available in the lower-level caches. Model caches are
dependent upon the datastore and portal access control caches. The figure only
features the most important caches.
Figure 2. Portal Model Cache Hierarchy
com.ibm.wps.model.factory.SimpleCacheKey
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache is a helper cache for other model caches used by the portal model
factory. It contains a small number of entries based on the model types
available in portal. In addition there can be one entry per active user
session. The size of this cache might be adapted to the number of active
sessions in one portal JVM. Re-creating a cache entry is a rather cheap
operation since it usually can be accomplished in memory. A cache entry is a
small object.
com.ibm.wps.model.content.impl.ResourceCache
Default size: 5000, default lifetime: 5600, usage pattern: regular.
This cache contains aggregated pages. In contrast to the data store page
instance cache this cache contains the complete models of pages and their
content, i.e. the portlets and containers on them. The page instance cache
rather holds the raw page data. This cache scales with the number of pages
defined in your portal and the different sets of access control rights on these
pages. This cache contains very ‘valuable’ information; it utilizes several
other caches, for example, page instance and access control caches, to build
its data. Hence creating a cache entry usually only requires in-memory
information, but can also lead to many database queries. The size of an entry
in the cache depends on the complexity of the pages, but typically the objects
are medium-sized, since they are usually made of references to other cached
data. The cache should be large enough to hold the most frequently accessed
pages multiplied with the number of different access control settings on these
pages. Increasing the cache lifetime can be useful if page definitions do not
change often in your environment.
Example: A portal has 500 pages and all users have the same permissions on
these. In addition there are another 50 pages; two groups of users have
different access rights on these pages. In this case a maximum of 600 entries
would be in the cache.
com.ibm.wsp.mode.content.impl.TopologyCache
Default size: 10000, default lifetime: 5700, usage pattern: regular.
This cache contains portal topology information, i.e. portal navigation
elements being composed of navigation nodes and their sorted, access
control-filtered children. Topology elements undergo several processing steps
from first loading from the database until finally being added to the cache.
This cache only contains the completely processed topology entities. This cache
is explicitly used during login and whenever a user navigates to a part of the
portal where he has not been before during the same session. If a cache entry
is not found, a private copy is created that is then further processed. Once
the private copy is completely processed -that does not happen for all
navigation nodes- it is added to the cache. If a user finds an entry in the
cache a reference is copied into his private topology model and additional
cache accesses are no longer necessary. Hence there is only one cache hit (or
miss) per user and navigation node. The cache scales with the number of
navigation nodes and the number of different sets of permissions on these and,
possibly, the derivation chain (children and parents) a page belongs to.
Entries in this cache are expensive to create; they rely on other cached
information, like the access control caches and the page instance cache. The
entries in the cache are medium-sized, being mainly some lists of references to
other cached data. The cache should be sized in a way such the most important
pages multiplied with all the different sets of permissions that exist on
theses page can be stored.
com.ibm.wps.model.factory.ContentModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This run-time cache contains the content models for portal users. There is one
entry per active portal user. The cache should be large enough to hold all
models for these users. An entry in the cache has the maximum lifetime of the
corresponding user session, i.e. entries are removed at the end of the session.
Creating a cache entry can be very expensive. Typically all required
information is in memory, but accessing the database, also many times, might be
necessary if underlying information is also no longer cached. Furthermore the
number of pages summarized in the model can be very large which also adds to
the time it takes to rebuild a cache entry. Building the content model is done
incrementally as required for the current request; the model is not built at
once. Depending on the size of the model also the memory requirements vary. The
more pages a user can access and has accessed already during the current
session the larger the cache entry, ranging from medium to very large. A cache
entry typically is composed of references to other cached and shared objects.
Hence an entry size is not made up by the number of page and all subordinate
objects but only contains references to these.
com.ibm.wps.model.factory.ContentModelCache.isolated
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains the administrative content models. There is one entry for
every user doing administrative work at a certain point in time. In so far the
number of entries in this cache typically is much lower than in the other
cache. But for this cache you should make sure that no cache entries of active
users are evicted. Compare with the content model run-time cache for all other
information.
com.ibm.wps.model.factory.NavigationSelectionModelCache.live<
br />
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This run-time cache contains the navigation selection models used by portal
users. There is one entry per user session. The cache should be large enough to
hold all these models for the active users. An entry in the cache has the
maximum lifetime of the corresponding user session, i.e. entries are removed at
the end of the session. Creating a cache entry is less expensive than creating
a content model cache entry. Typically all required information is in memory,
but accessing the database might be necessary. In comparison to the content
model cache creating an entry for the navigation selection model cache is much
cheaper. In addition also the in-memory size of elements in this cache is much
smaller since this type of model references fewer objects.
com.ibm.wps.model.factory.NavigationSelectionModelCache.isolated<
/b>
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains navigation selection models used by administrative users.
The details given for the administrative content model cache also apply
here.
com.ibm.wps.model.factory.URLMappingCache.live
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache is the run-time model cache for the URL mappings defined in your
portal installation. It should be large enough to hold all URL mappings defined
in your system. Creating an entry to the cache involves reading one entry from
the portal database. A cache entry is fairly small in size.
com.ibm.wps.model.factory.URLMappingCache.isolated
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache is the administration cache for URL mappings. The details given for
the other isolated caches also apply here.
com.ibm.wps.model.factory.MultiModelCache.live
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache contains run-time models for several different resource types in
WebSphere Portal, for example clients, supported markups and languages. One
entry, for example, is a list containing all supported markups. Those resources
typically remain stable for a long time, hence you should mostly experience
read accesses to this cache. Creating a cache entry involves reading the
corresponding data from the database. An entry can be fairly large, but the
number is very low so that the total size of this cache is negligible.
com.ibm.wps.model.factory.MultiModelCache.isolated
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache contains the administrative models for several portal resource
types. Typically this cache is empty and not used, because administration on
those resource types is a rare event. There is one entry for every user doing
administration on any of the resource types that are stored in the cache. The
creation behavior and size are similar to the run-time cache.
com.ibm.wps.model.factory.NavigationModelCache.live
Default size: 2, default lifetime: infinite.
This cache is not used in WebSphere Portal V6.0 and hence disabled. Changing
any of its properties does not have any effect.
com.ibm.wps.model.factory.NavigationModelCache.isolated
Default size: 2, default lifetime: infinite.
This cache is not used WebSphere Portal V6.0 and hence disabled. Changing any
of its properties does not have any effect.
com.ibm.wps.model.content.impl.DynamicLoadCache
Default size: 4, default lifetime: 600.
This cache is not used WebSphere Portal V6.0 and hence disabled. Changing any
of its properties does not have any effect.
com.ibm.wps.model.impl.RuntimeClientMap.userAgent2client
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache maps user agent strings, i.e. the identification strings sent by
browsers in the HTTP header, to client profiles. These profiles basically
correspond to CC/PP profiles. Hence the cache scales with the number of browser
identification strings. Data from this cache is accessed during every request.
Creating a cache entry is very cheap since the profile information is in memory
already. An entry in the cache hence is fairly small since already existing
data is referenced.
URL MAPPINGS
The following caches contain data on portal URL mappings. Be sure to
size the caches in a way such that these are large enough to hold all defined
URL mappings in your system.
wps.mappingurl.ContextsCache
Default size: 500, default lifetime: infinite, usage pattern: regular.
This cache contains URL mapping contexts. It scales with the number of mapping
contexts defined in the system. This cache is used if a URL mapping cannot be
resolved using the lookup cache. Creating an entry involves reading a mapping
entry from the database. An entry in the cache is medium-sized.
wps.mappingurl.LookupCache
Default size: 600, default lifetime: infinite, usage pattern: regular.
This cache is used as a final lookup cache for the computed mappings between (a
hierarchy of) URL mappings and a WebSphere Portal resource. It is accessed
during every request when analyzing the incoming URL for being a URL mapping.
The size of this cache should be the number of all mappings. Creating a cache
entry typically is cheap because the information often s in memory. An entry in
the cache is rather small.
VIRTUAL PORTALS
The following group of caches is only relevant if you have defined
additional virtual portals in your system. In all other situations it is safe
to set the size of these caches to one and the lifetime to infinite.
com.ibm.wps.services.vpmapping.VirtualPortalIDToRealmCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache stores the realm information for virtual portals. One realm can
contain several virtual portals, but one virtual portal can only be part of a
single realm. As a consequence, the optimum size of this cache is the number of
virtual portals defined in your environment. You may increase the lifetime for
better performance if your setup of virtual portals changes infrequently. If
you only use the default portal and no additional virtual portal, you will see
one entry in the cache and only little traffic on the cache. Creating a new
cache entry requires one database query. An entry into the cache is fairly
small.
com.ibm.wps.services.vpmapping.VirtualPortalIDToURLCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache maps virtual portal IDs to their respective LPID. The LPID usually
is used to create URLs for a specific virtual portal. Since the number of LPIDs
is equal to the number of virtual portal IDs, the optimum size of this cache is
the number of Virtual Portals defined in your environment. You may increase the
life time for better performance if your setup of virtual portals changes
infrequently. If you only use the default portal and no additional virtual
portal, you will see one entry in the cache and only little traffic on the
cache.
com.ibm.wps.services.vpmapping.URLToVirtualPortalIDCache
Default size: 120, default lifetime: 3600, usage pattern: regular.
This cache maps LPID values to virtual portal IDs. LPIDs are encoded in a URL
that points to a certain virtual portal. Therefore the number of LPIDs is equal
to the number of virtual portal IDs. Accordingly the optimum size of this cache
is the number of virtual portals defined in your environment. You may increase
the lifetime for better performance if your setup of virtual portals changes
infrequently. If you only use the default portal and no additional virtual
portal, you will see one entry in the cache and only little traffic on the
cache.
WSRP
All WSRP caches are only accessed if the portal is used as either a
WSRP consumer or producer. Each of the caches is used on either side of the
WSRP communication, but not on both sides. Most of the WSRP caches are used and
read during every WSRP request, either displaying a page with a provided
portlet on it, or administering WSRP properties. Exceptions to this general
rule are noted below.
wsrp.cache.portletdescription
Default size: 500, default lifetime: 3600, usage pattern: regular.
This cache contains the portlet descriptions delivered by producers. These
descriptions could be considered meta information on the provided portlets,
like languages and descriptions. It is used on the producer side. The cache
scales with the number of remote portlets provided by the producer. Increasing
the default lifetime can improve performance if portlet descriptions of the
provided portlets change infrequently. Rebuilding cache entries is rather
expensive. It includes loading data from the database with several calls. The
cached entries are rather expensive in terms of memory usage.
wsrp.cache.servicedescription
Default size: 150, default lifetime: infinite, usage pattern: regular.
This cache contains service descriptions of WSRP producers. It is used on the
consumer side. It scales with the number of WSRP producers integrated into the
consuming portals; there is exactly one description per producer. The service
description is generated using all the portlet descriptions from the producer
portal plus some additional data. Hence a service description can be large in
terms of memory requirements. Rebuilding the description requires several
roundtrips and is an expensive operation. Cache entries are rebuilt if a user
clicks the ‘Browse’ button in the WSRP administration portlets. This leads to a
refresh of all service descriptions of all producers. This cache is only used
during WSRP administration.
wsrp.cache.portlet.instance
Default size: 2500, default lifetime: 3600, usage pattern: regular.
This cache contains the proxy portlet instances on the WSRP consumer side and
is only used there. It scales with the number of integrated remote portlets
multiplied with the number of users having their own customizations of portlet
preferences for these remote portlets (portlet settings for legacy portlets
respectively). Creating an entry for the cache involves one multi-line database
query. The size of a cached entry depends on the number of parameters
associated with the portlet. Hence the size ranges from small to fairly
large.
wsrp.cache.producer.user
Default size: 5000, default lifetime: 3600, usage pattern: multiple object
types.
This cache contains the descriptor of the producer and context information
between users and producers. It is used on the consumer side. It scales with
the total number of active users accessing remote portlets of these producers,
i.e. as a maximum the number of producers multiplied with the number of active
users accessing them plus the number of producers. Recreating cache entry is
fairly expensive. It involves some DB queries and in-memory operations.
Therefore the session timeout should not be higher than the lifetime of entries
in the cache. Cache entries are explicitly invalidated during user session
destruction.
wsrp.cache.portlet.window
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache contains a WSRP specific wrapper on a WebSphere Portal portlet
entity object. It is used on the producer side. It scales with the number of
provided portlets and the number of occurrences of these portlets on consumer
pages. Recreating cache entries is rather cheap and typically only includes
in-memory operations. An entry into this cache is fairly small. This cache is
accessed very during a request.
wsrp.producer.portletpool.pops
Default size: 1000, default lifetime: infinite, usage pattern: cascading object
types.
This cache stores the Producer Offered Portlets and hence scales with their
number. The number of entries in this cache is identical to the number of
entries in the portletdescription cache. The WSRP object model data is stored
in here, though. Offered portlets are first looked up in this cache and, if the
lookup is not successful, the in the ccps cache (see below). Reloading cache
entries involves one query against the database. Cached entries are rather
small.
wsrp.producer.portletpool.ccps
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache stores the client configure portlets. It is used on the producer
side. It scales with the number of provided portlets and the number of remote
users having personalized those (Consumer Configured Portlets); hence the
maximum would be the number of provided portlets multiplied by the number of
remote users accessing the producer. Reloading cache entries involves one query
against the database. Cached entries are rather small.
DYNAMIC ASSEMBLY / PROCESS INTEGRATION
The following caches are used when dynamic UI functionality, often
together with WebSphere Process Server integration are used:
processintegration.PendingTasksCache
Default size: 2500, default lifetime: infinite, usage pattern: regular.
This cache contains the pending process tasks in the scope of a user. The size
of this cache scales with the number of users concurrently using process
integration functionality. Each cache entry consists of a complete set of
pending process tasks for a given user and therefore can be fairly large in
memory. Reloading a cache entry involves accessing the Human Task Manager via
an EJB call. The cache is always accessed when the PendingTasksTag is used in a
portlet JSP.
You should also configure the setting processintegration.pendingtasks.lifetime
in ConfigServices.properties which defaults to a value of 30 seconds. This
setting describes the interval at which a process engine is queried for pending
tasks of a user and the cache entries are updated.
wp.te.transformationAssociationCache
Default size: 500, default lifetime: infinite, usage pattern: regular.
This cache contains transformation extension nodes. So typically there are only
few entries in the cache. There is typically one access to the cache per
request. Building an entry to the cache involves one database query. One entry
is fairly small. Typically there is no need to modify the settings for this
cache.
POLICY
The WebSphere Portal policy manager uses the following caches:
com.ibm.wps.policy.services.PolicyCacheManager
Default size: 1000, default lifetime: 7780, usage pattern: regular.
This cache stores the policies. Out of the box portal comes with twelve theme
policies and one mail policy, each of them being one entry into the cache.
Hence the maximum number of cache entries depends on your system and the number
of custom policies. This cache is accessed fairly often, if you use policies at
all. The WebSphere Portal V6.0 default theme uses policies and query this cache
during every request, but it is possible to create themes that do not use
policies at all. Furthermore when opening mails the cache is accessed. Creating
a cache entry involves reading data from a database. An entry into the cache is
fairly small.
com.ibm.wps.policy.services.UserPolicyNodeCacheManager
Default size: 2500, default lifetime: 600, usage pattern: regular.
This cache stores connections between a policy and a policy target, for example
a user distinguished name. Theme policies do not use targets, hence there is no
cache entry based on these policies. The out-of-the-box mail policy uses the
user as target. Hence there is at least one entry for every user accessing the
CPP mail portlet. The size of a cache entry depends on the size of the target
object. For a distinguished name a cache entry is fairly small.
COLLABORATION SERVICES
All of the following caches are used by the DEPP portlets and some
services around these portlets. In so far the caches are not used if the DEPP
portlets are not utilized in the portal system. These caches store credential
information needed for the backend servers, server information for these
servers and user information that would otherwise require LDAP lookups.
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.serve
r
Default size: 50, default lifetime: infinite, usage pattern: regular.
This cache stores mail server information. In so far it scales with the number
of different mail servers used in the environment. It is accessed whenever a
mail server is accessed. Creating a cache entry requires one LDAP search. An
entry in the cache is fairly small.
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user<
/code>
Default size: 2000, default lifetime: 10780, usage pattern: regular.
This cache stores user-specific information read from the LDAP. It scales with
the number of users working with DEPP portlets. The cache is accessed during
rendering a DEPP portlet, whenever those need user information. This could be
multiple times per page reload. In addition the cache is accessed whenever a
mail server is accessed. Creating a cache entry is fairly expensive and can
involve multiple LDAP lookups. An entry into the cache is medium-sized.
com.lotus.cs.services.directory.wmm.WMMDirectoryService
Default size: 4000, default lifetime: 10980, usage pattern: regular.
This cache stores user-specific information read from the LDAP and WMM. Entries
in this cache represent a more complete set of data stored in the LDAP than is
available in other parts of WebSphere Portal. The cache scales with the number
of users working with DEPP portlets. The cache is accessed during rendering a
DEPP portlet, whenever those need user information. This could be multiple
times per page reload. In addition the cache is accessed whenever a mail server
is accessed. Creating a cache entry is fairly expensive and can involve
multiple LDAP lookups. An entry into the cache is medium-sized.
com.lotus.cs.services.UserEnvironment
Default size: 2000, default lifetime: 10880, usage pattern: regular.
This cache stores user-specific information. Entries represent a compilation of
credential information for one user to different LDAP directories and details
which data on the given user can be found in which directory. For example, the
general info may be stored in one directory, but the mail server and file may
be in another. The cache scales with the number of users working with DEPP
portlets. The cache is accessed whenever a DEPP portlet is accessed. Creating a
cache entry can be fairly expensive since multiple resources might be queried.
An entry to the cache is medium-sized.
com.lotus.cs.services.domino.DominoService
Default size: 2000, default lifetime: 11080, usage pattern: regular.
This cache stores user-specific Domino information. It is used for awareness
functions. It scales with the number of users working with the corresponding
function. The cache is accessed whenever awareness functions are requested
during page rendering. Creating a cache entry is cheap and simply involves
creating a new Domino session. An entry to the cache is medium-sized.
MISCELLANEOUS
This group of caches does not fit in any of the other
categories.
com.ibm.wps.pe.portletentity
Default size: 10000, default lifetime: 5800, usage pattern: regular.
This cache contains configuration for portlets on pages (portlet instances,
shared and per-user). It scales with the number of pages defined in your
portal, the number of portlets on the pages and the number of portlet instances
that have been personalized by users. The cache is accessed many times during
portal page rendering. In so far it is important that the most relevant portlet
entities are cached. Creating a cache entry involves a single database lookup.
An entry into the cache is fairly small.
Example: In a portal with 500 pages and on average three portlets per page,
the optimal cache size would be 1500 to store all possible portlet entity data
in the cache, if users are not allowed to personalize the portlets. If the
portal has 100 users that are logged in concurrently and these users have
personalized 50 portlets on average, the required cache size to cache all data
would be 6500. These numbers give the maximum number of entries to the cache.
Typically for this cache it is not required to have all portlet entities in
memory, because most users will not view all pages so that not all personalized
data must be loaded. The most frequently accessed un-personalized portlet
entities should fit into the cache, though.
com.ibm.wps.services.cache.cachedstate.CachedStateServiceCache.cache
Default size: 50000, default lifetime: 7200, usage pattern: typically
regular.
This cache stores session-scoped data in the portal context and is used by
various portal components. This cache scales linearly with the number of active
sessions in the system and the number of portal components using this cache for
data retrieval. The usage pattern, access times, entry creation costs and entry
memory sizes depend on the portal component using this cache and cannot be
stated in general.
wp.xml.configitems
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This cache stores XML Access configuration items. It is used only during XML
Access processing. The entries resemble references between nodes in the XML
Access document. Especially when working with complex XML files, usually used
for imports or Release Builder processes, it can be beneficial to increase the
cache size. The cache will be cleared after XML processing is completed.
Reloading a cache entry involves one database query. Entries in the cache are
medium-sized.
PortletMenuCache
Default size: 200, default lifetime: infinite, usage pattern: regular.
This cache contains portlet menu trees for all portlets that define their
portal menu as global, meaning identical for all users. The portal
functionality that utilizes this cache is deprecated with WebSphere Portal
Version V6.0.
RegistryService
Default size: 32, default lifetime: infinite, usage pattern: regular.