Advanced page caching techniques include caching pages and blobs, where they are cached, and how they are retrieved from cache on both WebCenter Sites and Satellite Server systems.
Topics:
Caching improves the speed at which WebCenter Sites serves pages. The caching-rendered content doesn’t need to be re-rendered at each request. This improves the response time.
The caching system has multiple layers. This allows cached objects to be regenerated on one cache level, while the client is being served cached content from another cache level. WebCenter Sites is the inner level of cache, and Satellite Server is the outer layer of cache.
Both WebCenter Sites and Satellite Server cache pages, pagelets, and blobs. WebCenter Sites provides three different rendering engine caches: CS page cache, BlobServer cache, and SS cache.
All the caches can be configured and emptied as follows:
For information on setting expiration times for WebCenter Sites cache and BlobServer cache, see Setting Expiration Time for an Individual Entry.
For information on removing objects from the cache for WebCenter Sites cache, BlobServer cache, and Satellite Server cache, see Explicitly Removing Entries from Cache.
There are two levels of caching for the WebCenter Sites page cache:
In the database.
In memory. Memory cache is a transparent subset of the database cache; however, it is independently configurable.
See these topics:
The WebCenter Sites database cache does not have a maximum size configuration option. The memory subset of the page cache lets you specify the maximum number of entries present.
Set a positive integer in the cc.SystemPageCacheCSz property in the wcs_properties.json file to specify the maximum number of entries allowed to exist in the cache.
Note:
Setting a value of 0 causes all entries to be added and then promptly removed. However, this should be avoided.
The cc.SystemPageCacheCSz property must not be set to -1.
The cache uses a Least Recently Used (LRU) algorithm to identify which entry to prune when the maximum size has been reached.
The maximum size does not reflect the aggregate number of bytes stored in cache.
The lifetime of an entry in the page cache is determined by the cscacheinfo setting. The CacheInfo object derives values that are not explicitly set in the cscacheinfo field from the configuration file. For CacheInfo syntax, see CacheInfo String Syntax.
WebCenter Sites provides two ways of removing entries from cache: manually and automatically, using CacheManager.
You can remove an entry from the page cache manually using the CacheServer servlet. The CacheServer provides two options:
Flush the entire cache.
Force a flush of all pages at the moment they expire. To invoke the CacheServer flush all functionality, you must be logged in as a user with destroy privileges on the SiteCatalog table, and specify the parameter all=true when invoking the CacheServer servlet. If you do not specify a parameter, then all expired entries (those whose expiry date is in the past) are cleared from the cache immediately. Entries that have not yet expired are not cleared.
Note:
In no case will an expired entry be served from the cache, even if it is still in the database table. WebCenter Sites checks the expiry date of any page it retrieves from cache before serving the page. If WebCenter Sites attempts to serve a page that has expired, the page will be removed from the cache immediately and a new page will be generated.
CacheManager is a module closely tied into the WebCenter Sites page and blob cache mechanisms. It lets you manage the contents of all of the rendering caches based on the items loaded on a page, on the expiration of the pages, or on parameters passed into pages.
CacheManager alone could be the subject of an independent document. An overview of its functionality is provided here. For complete information about methods and required arguments, consult the COM.FutureTense.Cache.CacheManager Javadoc.
You can use these methods to take advantage of double-buffered caching, a tool that can enable extremely high performance dynamic sites. See Understanding Page Design and Caching.
The BlobServer cache is an all or nothing cache. Its entries are either globally cached or globally not cached. BlobServer caching is disabled if security is enabled, or if bs.security=true.
See these topics:
The property bs.bCacheSize in the WebCenter Sites wcs_properties.json file specifies the number of entries the blob cache contains. If the size is set to a negative number, the blob cache is allowed to grow indefinitely.
Blob Server does not support expiration for cached entries. All cached objects reside in cache for the timeout determined by the bs.bCacheTimeout property in the WebCenter Sites wcs_properties.json file. A negative timeout indicates that entries should not time out. A positive integer specifies the number of minutes an object resides in cache.
You can use BlobServer to flush either individual entries or all entries from the cache.
To remove an entry from cache manually, rename the blobtable parameter to flushblobtable. This removes the entry corresponding to the rest of the parameters from the cache.
To remove all entries from the cache manually, there are two options.
Invoke the BlobServer servlet with the parameter flushblobtables (notice the "s").
Invoke the CacheServer servlet as described above. Note that this flushes all pages and all blobs from the cache.
Because blob dependency items are recorded when blob links are generated, you may invoke CacheManager to manage blobs and pages. CacheManager always manages blobs and pages together. See CacheManager, About the CacheManager, and Enabling CacheManager.
Note:
Developers should check the asset status before serving blobs. This avoids issues such as the BlobServer serving a blob after an asset has been voided (this behavior occurs with basic assets only).
You configure the generic Satellite Server cache in the wcs_properties.json file.
However, cache configuration is often overridden on an object-by-object basis.
Update the cache_max property in the wcs_properties.json file to the maximum number of entries that can be stored in the cache at once.
If you set the property to a negative integer, the cache is not limited by size. Any positive integer specifies the maximum number of entries that can be stored in the cache.
You can remove individual entries from the Satellite Server cache either manually or using CacheManager, as explained in this section.
Manual Removal: Satellite Server includes a servlet called FlushServer. By submitting a GET request to this servlet, specifying the user name, password and reset parameters, it is possible to flush all of the contents of the Satellite Server cache. It is not possible to flush individual entries using GET.
Automatic Removal: It is possible to flush the Satellite Server cache using CacheManager. CacheManager is only able to flush entries on Satellite Server if a corresponding object is cached on WebCenter Sites. This is because of the way WebCenter Sites tracks the contents of the Satellite Server cache.
When the Satellite Server cache is flushed by using CacheManager, a corresponding object is cached on WebCenter Sites. The corresponding object is required because of the way WebCenter Sites tracks the contents of the Satellite Server cache.
The relevant CacheManager methods for dealing with the Satellite Server cache are flushSSEngines() and refreshSSEngines(). See Explicitly Removing Entries from Cache.
The cscacheinfo and sscacheinfo fields of the SiteCatalog are populated with a CacheInfo string. Learn how the format of the two-part, comma-separated string determines whether the page is to be cached and when it expires.
Sample values are as follows:
false true true,* true,~4 true,@1987-06-05 04:32:10 true,#00:00:00 */*/* * (blank)
CacheInfo String: First Part
The first part in CacheInfo must be one of the following values:
false true (blank)*
If the value is false, then the page is not cached.
If the value is true, then the page is cached according to the information provided in the second element.
If the value is blank, then the wcs_properties.json property cs.alwaysusedisk is checked. If this property is set to yes, then a blank value is interpreted as having the same behavior as true. If the value is set to no (the default value), then a blank value is interpreted as having the same behavior as false.
If the value is *, then it is treated as blank.
CacheInfo String: Second Part
This describes when a page that is to be cached should be removed from cache. If the first element is false (or is interpreted as false), then the second element is ignored.
There are three ways of specifying the expiration of a page:
page timeout (in minutes) instant in time expiration cron-like TimePattern expiration
Legal values include:
~<number of minutes> @<date in JDBC format> #<COM.FutureTense.Util.TimePattern format> * (blank)
Page Timeout
If the second element starts with the tilde symbol (~), then the following value must be an integer. The value of this integer is the number of minutes a page will remain in cache after it was first created. A negative value or 0 indicates that the page will never expire (it will remain in cache forever).
Absolute Moment in Time
If the second element starts with the at symbol (@), then the following value must be a date expressed in the JDBC date string format, that is, YYYY-MM-DD HH:MM:SS. Once that date has passed, cached pages are flushed from cache and the page is no longer cached.
TimePattern
The TimePattern format is supported for describing page cache expiration. If the second element starts with a hashtag (#), then the following value must be a valid TimePattern string as defined by the public class COM.FutureTense.Util.TimePattern.
In general, the TimePattern syntax corresponds to the format used in most UNIX cron tables. It lets you specify expiration at a specific time or times every day, month, week, day of week, and year.
The TimePattern format is expected to become the most widely used format for page expiration.
Wildcard
If the second element is *, then the page will assume a timeout expiration behavior, as described in Page Timeout. The timeout value is read from the wcs_properties.json file cs.pgCacheTimeout property.
Blank
If the second element is blank, then it assumes the same behavior as *.
Ideally, a WebCenter Sites webpage should have a maximum of six to ten cached primary pagelets served by Remote Satellite Server. Too many cached pagelets lead to overcaching and adversely affect the system performance.
These topics describe practices that prevent overcaching and improve response times and throughput:
Design page templates in such a way that there are fewer uncached pagelets per page. The default style=pagelet from the <render:calltemplate> tag is not always the best choice. Fewer pagelets per page improve response times and throughput.
Switch from Remote Satellite Server to Co-Resident Satellite Server if you already have page templates and redesigning them is not feasible. No roundtrips are required between the WebCenter Sites servlet and Co-Resident Satellite Server. Co-Resident SatelliteServer is likely to give better response times than Remote Satellite Server when there are more uncached pagelets on a page.
Reduce the number of cached pagelets by combining them. First check if each <render:calltemplate> call is using the pagelet default style attribute value. Reduce the number of pagelets by inlining the <render:calltemplate> calls as element calls (style=element).
The typical use case for specifying style="element" is when the outer calling template (whether page or pagelet) shares the same c, cid as an inner called pagelet template. Since both cached objects expire at the same time (that is, they have the same asset dependencies), there is no advantage in caching them separately.
Rather than caching subpagelets directly on Remote Satellite Server, back up subpagelets through pagelet cache on the ContentServer servlet by using the style="embedded" variant. That is, inline the <render:calltemplate> calls as ContentServer page fragments (style=embedded).
For example, if a list of product summaries in a webpage contains ten items, it means the default style="pagelet" is applied to each of them. Due to the pagelet style, ten roundtrips between the WebCenter Sites servlet and Remote Satellite Server would be required to render this list. However, if existing <render:calltemplate> calls for the subpagelets are set to use style="embedded" -- while ensuring to cache the outer list template itself -- then just one roundtrip for the entire product list pagelet is required. This is because only the outer template is served by Remote Satellite Server with the remaining subpagelets only served back on the ContentServer servlet.
When the cid is passed to every cached pagelet, the cache is not shared between webpages. For example, a site may contain 5,000 webpages, all of which pass the cid to the leftnav. There would also be 5,000 leftnavs cached independently of the calling webpage. This scenario can produce two situations:
When a single Page asset in the site navigation tree is edited and published, all 5000 leftnavs uncache. This is because the Page asset just published has logged a dependency to all leftnav pagelets.
When a single Article asset is edited and published, both the cached outer webpage (typically the Layout template) and the leftnav are uncached and need to be re-evaluated. Because cid is passed to leftnav, Content Server uncaches outer webpage and leftnav as well. This approach is not efficient since the Article has nothing to do with the Site Navigation hierarchy.
To avoid overcaching in these situations, change the leftnav so that it always takes a Page cid, and not just any cid. The calling template should be able to determine what Page it belongs to so that it can pass that as a cache argument. Only the Page cid should log a cache dependency to the pagelet and no other Page assets. Pseudocode is as follows:
If c is not "Page"
then
Calculate the site navigation PageNode by doing a reverse look up of the Page from the current asset's cid.
Alternatively, have the site navigation Page as an attribute of the current asset and simply fetch it.
then calculate the PageNode from that
else
Calculate the PageNode from the current Page cid.
This way, the cached version of this pagelet is bound to the owner's related Page asset alone. When a single Page asset is edited in the site navigation tree and published, only a single leftnav, whose cid=<the current Page asset>, will uncache. When a single Article asset is edited and published, only the cached outer webpage (typically the Layout template) needs to be re-evaluated.
When editors are updating and changing the system on a daily basis, developers' choices have a huge impact on the efficiency of the system. Without the suggested improvement, even editing a single asset can cause the system to do a lot more work at publish time than required. The arguments that are explicitly passed to each pagelet have a direct impact on overall performance.