This chapter describes how WebCenter Sites caching works. Caching your web pages can improve your site's performance. Whether your site is static or dynamic, you need to design your site so that part or all of a given page is cached.
This chapter contains the following sections:
It is recommended that you design your web pages using a modular page design strategy, where a web page that a website visitor sees is composed of multiple elements. Modular page design has several benefits:
It improves system performance by allowing you to develop an efficient caching strategy
It lets you code common design elements, like navigation bars, one time and use them on multiple web pages
The following diagram shows a simple modular page:
Each rectangle represents a pagelet (the generated output of one or more elements). These pagelets are called by a containing page. The containing page lays out how the pagelets appear on the finished page and contains any code that must be evaluated each time the page is viewed (custom ACL checking code, for example). This strategy lets you code an element once and use it in many places in your website.
WebCenter Sites lets you cache entire web pages and/or the components that make up those web pages. An efficient page caching strategy improves system performance by reducing load.
Two members of the WebCenter Sites product family implement page caching:
WebCenter Sites, which caches pages on the WebCenter Sites system
Satellite Server, which provides a second level of caching for your WebCenter Sites system, and can also be used as a remote cache for your web pages
WebCenter Sites utilizes both the WebCenter Sites and Satellite Server caches to create an efficient caching strategy.
Pagelets generated by requests to the ContentServer servlet can be cached on disk. If a page is accessed frequently and its content depends on a small number of parameters, then it is a good candidate for disk caching.
To disk-cache a pagelet, you use one of the following tags:
|JSP Tag||XML Tag|
If the pagelet that you want to cache is not already in the disk cache, ContentServer adds it to the cache and then serves the pagelet. If the specified pagelet is already in the disk cache, ContentServer simply serves it.
The expiration of disk-cached pagelets is time-based and governed by properties in the
futuretense.ini file, in conjunction with the values set in the
sscacheinfo columns of the
SiteCatalog table (
cscacheinfo corresponds to the WebCenter Sites servlet;
sscacheinfo corresponds to the Satellite Server servlet). When a cached page is requested, its expiration time (cache timeout) is stored in the
etime column of the
SystemPageCache table. The expiration time for cached pages requested through the WebCenter Sites servlet is calculated from the
cscachinfo value, and the expiration time for cached pages requested through the Satellite Server servlet is calculated from the
sscacheinfo value. Items in cache are bound by the same security rules as uncached pages; WebCenter Sites ACLs apply to cached pagelets just as they do to elements.
The term blob is an acronym for binary large object. Although a blob is usually an image file, a blob can be any binary object, including a Microsoft Word file or a spreadsheet. Most websites serve a number of blobs.
To serve blobs, WebCenter Sites offers a special servlet called BlobServer. The BlobServer gathers a blob from a table and performs all relevant security checks.
You access BlobServer with the BlobServer tags:
Both of these tags cache blobs in the WebCenter Sites and Satellite Server caches. For more information about the BlobServer tags, see the Oracle Fusion Middleware WebCenter Sites Tag Reference.
To delete a specific blob from the WebCenter Sites cache, you must do the following in the BlobServer URL:
blobtable parameter to
Authenticate as a user with
SiteGod privileges by passing credentials through the
To delete all blobs, rename the blobtable parameter to flushblobtables (notice the "s") and set its value to
Satellite Server, automatically installed with WebCenter Sites, provides an additional layer of caching. To improve your WebCenter Sites system's performance, you can add remote Satellite Server systems, putting your content closer to its intended audience.
Satellite Server caches pages, pagelets, and blobs to disk or to memory. You can use the
Inventory servlet to view the contents of the memory and disk caches in varying degrees of detail. Note that items cached on Satellite Server are not protected by WebCenter Sites APIs. You can overcome this limitation by using the caching strategy outlined in Section 220.127.116.11, "Pagelet Caching Strategies."
Satellite Server caches small items to memory and large items to disk. You control the definitions of small and large through the
file_size property. For more information on setting Satellite Server properties, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.
On a busy site, each Satellite Server system's cache fills up quickly with the most popular pages. When the cache is full, Satellite Server deletes old pages to make room for new ones. Satellite Server uses a Least Recently Used algorithm (LRU) to determine which items should be removed from the cache. In other words, when a new page needs to be cached, Satellite Server removes the page that hasn't been accessed for the longest time. For example, given two cached pages, one that hasn't been accessed in 36 hours and the other that hasn't been accessed in 2 hours, Satellite Server removes the page that hasn't been accessed in 36 hours.
Page and pagelet expiration on Satellite Server is specified in the
sscacheinfo column of the
SiteCatalog table. Each time a page or pagelet is invoked through Satellite Server, Satellite Server processes the
sscacheinfo field's value and determines when the page or pagelet should expire. Consult Section 7.4, "CacheInfo String Syntax" in Chapter 7, "Advanced Page Caching Techniques"for information about the
Deprecation notice: It is possible to override the
sscachinfo expiration information for pagelets by specifying the
cachecontrol attribute in the
render.satellitepage tags. However, this practice is deprecated because it can lead to non-deterministic behavior; some pagelets may be accessed through the default method (without the
cachecontrol attribute) while others may be accessed with an override. The first method invoked will set the expiration for Satellite Server, and the second one will have no effect on the expiration.
Blobs cached on Satellite Server expire using the following algorithm:
You can use Satellite Server tags to override the default expiration time on a blob-by-blob basis.
If there is no Satellite tag to override the default expiration, Satellite Server gets the expiration time from the value of the
satellite.blob.cachecontrol.default property. This property is described in Section 18.104.22.168, "WebCenter Sites Page Caching Properties."
If no value is set for the
satellite.blob.cachecontrol.default property, Satellite Server gets the expiration time from the value of the
expiration property, described in Section 22.214.171.124, "Satellite Server Properties."
The following sections describe how the Satellite servlet caches web pages and how you can implement Satellite Server caching on your site. Use caching with the Satellite servlet in tandem with modular page design to create a fast, efficient website.
The Satellite servlet allows caching at the pagelet level. To implement caching with the Satellite servlet, you use Satellite Server XML or JSP tags in your WebCenter Sites pages, and you access pages using special Satellite URLs.
For example, suppose that you used the Satellite servlet to implement pagelet-level caching on a web page named
myPage. As shown in Figure 5-2, this page is composed of a containing page and three pagelets; A, B, and C. The containing page and pagelets A and B are already cached on a Satellite Server system, but pagelet C is not cached.
When a user requests
Satellite Server examines the URL. If it is a Satellite URL, the Satellite servlet gets the cached copy of the containing page. The servlet then looks for pointers to pagelets which are not currently in its cache, and requests those pagelets from WebCenter Sites. So, in our example, the Satellite servlet gets the containing page, and gets pagelets A and B from its cache.
The Satellite servlet requests Pagelet C from WebCenter Sites.
WebCenter Sites parses the appropriate XML to create Pagelet C and sends it to the Satellite servlet.
The Satellite servlet assembles Pagelets A, B, and C into the page, and sends the assembled page to the requester. The servlet also caches Pagelet C.
To implement pagelet-level caching with the Satellite servlet, you add Satellite tags to your WebCenter Sites templates. You do not develop any XML, JSP, or Java code on Satellite Server systems. In fact, Satellite Server does not know how to parse XML.
The Satellite tags in your elements are interpreted by the Java code you installed as part of Satellite Server. If this code is being called with a Satellite URL, it generates the information that the Satellite servlet uses to cache and construct the pagelets. If you do not call an element containing Satellite tags with a Satellite URL, the resulting page functions as if the Satellite tags were WebCenter Sites tags.
Satellite URLs look like the following example:
port are the hostname and port number of your Satellite Server computer, and
page is the name of the page you are requesting. A Satellite URL can also include name/value pairs you want to pass to the called page.
The following sample code uses the
render:satellitepage tag to call a pagelet. If the pagelet is not already in Satellite Server's cache, the Satellite servlet loads and caches the page. If the pagelet encounters an error during the processing and cannot be evaluated, it is not cached.
render:satellitepage tag (and the
satellite:page tag and their xml equivalents) identifies a cached pagelet by the pagename and name/value pairs passed to it. If the parameters or the name/value pairs differ from one invocation to another, a different pagelet will be cached, even if the content generated is the same. It is important to use name/value pairs to pass arguments to a pagelet through these tags.
Values passed through the ICS object pool, ICS List pool, page attribute context, and session (including session variables) may not be available to all called pagelets, because nested pagelets may not always be called at the same time as the parent. Furthermore, pagelets that rely on session or context data are rarely cacheable anyway, so attempting to cache them can result in non-deterministic behavior.
All parameters passed to a nested pagelet through
render:satellitepage (and the
satellite:page tag, and their xml equivalents) must be specified in the SiteCatalog as page criteria. This is WebCenter Sites's way of determining which parameters are relevant when building a pagelet for caching. Parameters other than those listed in the SiteCatalog are not permitted (an error indicating this will be written to the log).
<cs:ftcs> <html> <body> <render:satellitepage pagename="My/Sample/Page" /> </body> </html> </cs:ftcs>
Using Satellite tags to load and cache a blob is similar to the way you use Satellite tags to load and cache a pagelet. The following sample code adds to the previous example by calling a blob as well as a pagelet.
Line 7 uses the
ics:selectto tag to perform a simple SQL query that retrieves a blob from the database. Results are returned in the form of an
Line 12 uses the
satellite:blob tag to load the blob that was retrieved from the database. As with the
satellite.page tag, if the blob is not in Satellite's cache, Satellite will load and cache the blob. The
cachecontrol parameter is set so that the blob will expire at a given time; in this case, every 30 minutes.
<!-- NOTE: This will fail if list has no content (== null) -->
<ics:setvar name="category" value="logo"/>
<ics:setvar name="errno" VALUE="0"/>
<!-- Test a blob -->
<render:satelliteblob service="img src"blobtable="SmokeImage" blobkey="id" blobwhere="imagelist.id" blobcol="urlpicture" blobheader="image/gif"cachecontrol="*:30:0 */*/*"alt="imagelist.alttext" border="0" />
If there are binary files (or blobs) on your site that seldom change or never change, such as company logos, and you are using the Satellite servlet to cache at the pagelet level, you can improve performance by using an alternative method to serve these blobs.
To serve never-expiring blobs
Copy the never-expiring images to all your Satellite Server hosts. Place them under the doc root for your web server.
Access the images through
<img src="pathname"> HTML tags rather than through
satellite:blob Satellite tags.
For example, consider a never-expiring corporate logo file named
CorporateLogo.gif. To use the alternative method of serving blobs, you would first copy the file to the web server's doc root on all your Satellite Server hosts. Then, instead of serving this logo through a
satellite.blob tag, your element could simply use a tag like the following:
Be careful when using this mechanism for serving never-expiring images. For example, Satellite Server cannot warn you that one of the Satellite Server hosts does not contain the same image file as the other hosts.
The expiration of the page is controlled by the
expiration property. For more information on the
expiration property, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.
The Inventory servlet lets you view the various items stored in the cache. You invoke the Inventory servlet by using the following URL:
The host name and port number of the Satellite Server host whose cache you want to view.
The user name that you enter to log you in to the Satellite Server host.
The password that you enter to log you in to the Satellite Server host.
The type of information you wish the Inventory servlet to display. Valid values are:
If you do not supply the
The header contains the following information:
The host that this Satellite Server system forwards requests to.
Maximum cache objects
The maximum number of items allowed in the cache.
The number of items currently in the cache.
Cache check interval
How often the cache is checked for expired items, in minutes.
Default cache expiration
The value of the
Minimum file size (in bytes)
Items larger than this value are stored in files. Items smaller than this value are stored in RAM.
The WebCenter Sites CacheManager object maintains both the WebCenter Sites and Satellite Server caches. CacheManager can do the following:
Log pagelets in the cache tracking tables.
Keep a record of the content (assets) that pages and pagelets contain by recording cache dependency items in cache-tracking tables. Cache dependency items are items that, when changed, invalidate the cached pages and pagelets that contain them. A cache dependency item is logged as a dependency for the current page and all of that page's parent pages.
Remove pages and pagelets containing invalid items from the WebCenter Sites and Satellite Server caches.
Rebuild the WebCenter Sites and Satellite Server caches with updated pages and pagelets after the invalid pages have been removed.
SiteCatalog table lists the pages and pagelets generated by WebCenter Sites. An element must have an entry in the
SiteCatalog table to be cached on WebCenter Sites and Satellite Server.
The fields in the
SiteCatalog table set the default behavior of a WebCenter Sites page, including default caching behavior. For more information on the
SiteCatalog table and its fields, see Section 23.4, "Creating Template Assets" and Section 23.6, "Creating SiteEntry Assets."
Items stored in the WebCenter Sites and Satellite Server caches are given a name called a cache key. The cache key uniquely identifies each item in the cache. CacheManager locates items in the cache using the cache key. WebCenter Sites and Satellite Server generate cache keys automatically, based on the values in the
pagecriteria fields of the
SiteCatalog table, and other internal data.
You include variables used by the page in the cache key by specifying them in a comma-separated list in the
pagecriteria field of the
SiteCatalog table. For example, suppose that you have a page called
myPage which uses the values
blue. To include
blue in the
myPage cache key, enter:
favoritecolor,second_favoritecolor in the
pagecriteria column and
n the resargsl column
WebCenter Sites and Satellite Server use the
pagecriteria and parameters that are passed to cached pages to help generate the cache keys. If the parameters differ from one invocation to another, a different page will be cached even if the content being generated is the same. For example:
calls a different page than:
whether or not the content being generated is the same. Values passed in by the URL override values set in
pagecriteria. For example, you have the
pagecriteria set to
If the URL passes in a value of
red,blue) will go into
myPage's cache key.
If the URL passes in values of
red,blue) will go into
myPage's cache key.
If the URL passes in values of
green,violet,yellow, an error results.
If a page does not have
pagecriteria set, the values in the
resargs fields go into the cache key. As with
pagecriteria, values passed in by a URL override values specified in the
The default cache settings for WebCenter Sites and Satellite Server are contained in the
futuretense.ini file. Additional Satellite Server properties are contained in
satellite.properties. All properties can be modified by use of the Property Editor.
This section summarizes the WebCenter Sites and Satellite Server caching properties. For detailed information about the properties and the Property Editor, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.
The following properties in
futuretense.ini control disk caching on WebCenter Sites:
cs.pgCacheTimeout, which specifies the default timeout for pages in the WebCenter Sites cache.
cs.freezeCache, which controls whether the cache pruning thread should run to remove expired entries from the cache.
cs.nocache, which disables the entire WebCenter Sites page cache.
cc.SystemPageCacheTimeout, which specifies the number of minutes a cached page is held in memory.
cs.alwaysUseDisk, which specifies the default behavior for page entries in the SiteCatalog that have no cache override property specified.
cc.SystemPageCacheCSz, which specifies the maximum number of pages that can be cached in memory.
Satellite Server has two sets of properties (given in detail in the Oracle Fusion Middleware WebCenter Sites Property Files Reference):
One set of properties is in the
futuretense.ini file on your WebCenter Sites system and includes the following:
satellite.page.cachecontrol.default, a deprecated property that specifies a default value for the
cachecontrol parameter for the
RENDER.SATELLITEPAGE tags and their JSP equivalents.
satellite.blob.cachecontrol.default, which specifies a default value for the
cachecontrol parameter for the
RENDER.SATELLITEBLOB tags and their JSP equivalents.
The other set of properties is in the
satellite.properties file on each Satellite Server host and comprises the following:
cache_folder: Specifies the directory into which Satellite Server will cache pagelets to disk.
file_size: Separates disk-cached pagelets and blobs from memory-cached pagelets and blobs according to the size that you specify.
expiration: Sets the default value for the length of time blobs stay in Satellite Server's cache.
cache_check_interval: Controls the frequency of the cache cleaner thread, and therefore when expired objects are pruned from cache.
cache_max: Specifies the maximum number of objects (pagelets and blobs) that can be cached (memory cache and disk cache combined) at a time.
WebCenter Sites and Engage implement a double-buffered caching strategy, which uses the WebCenter Sites and Satellite Server caches in tandem on your live website. This double-buffered caching strategy ensures that pages are always kept in cache, either on WebCenter Sites or Satellite Server.
You can implement a similar caching strategy if you are running the WebCenter Sites core and Satellite Server without any of the other CS modules or products, by using the CacheManager Java API. For more information about the CacheManager Java API, see the Oracle Fusion Middleware WebCenter Sites Java API Reference.
Both the WebCenter Sites core and Satellite Server caches are maintained by WebCenter Sites's CacheManager object. CacheManager tracks when content changes by logging elements and the assets that those elements call in cache tracking tables.
When assets are updated and published, WebCenter Sites and Satellite Server caches are automatically flushed and updated in the following order:
Content providers publish updated assets to the delivery system. CacheManager checks the cache tracking tables to see which cached items are affected by the updated assets.
CacheManager flushes the outdated
Page1 from the WebCenter Sites cache, then reloads the WebCenter Sites cache with the updated
Any requests for
Page1 will be served the old version of
Page1 from the Satellite Server cache. This protects the WebCenter Sites computer from undue load as it deletes and rebuilds its cache.
CacheManager flushes the outdated items from the Satellite Server cache. As visitors come to the website and request
Page1, the Satellite Server searches to see if
Page1 is in its cache. Because
Page1 is not in the Satellite Server cache, the request is passed on to WebCenter Sites.
The Satellite Server system's cache is filled with an updated version of
Page1, taken from the WebCenter Sites cache. The updated page is served to the requestors. If
Page1 were requested again, the page would be served from the Satellite Server cache.
The first step in implementing double-buffered caching on your website is to design modular pages, as described in Section 5.1, "Modular Page Design." Once you have developed a modular page design, you implement a double-buffered caching strategy in three steps:
Develop a pagelet caching strategy
Set how individual pages and pagelets are cached by using the
pagecriteria field of the
Code your elements with Satellite tags
With a modular page design, caching occurs at the pagelet level; the containing page is never cached, so that any cached pagelets are always protected by ACLs. You choose which pagelets get cached based on how frequently they are updated.
The following table summarizes the guidelines for caching pagelets:
|Cache a Pagelet||Don't Cache a Pagelet|
The following diagram is an example of a modular page:
The containing page should never be cached; this lets you put logic, which requires evaluation by WebCenter Sites, into your pages, while still gaining the performance benefits of caching. It also allows your page to be protected by WebCenter Sites ACLs.
The header and footer pagelets in this example should be disk cached. They rarely gets updated, and should be designed accordingly. The header and footer may be static HTML written into your template, or disk-cached content from WebCenter Sites.
The sidebar is also a good candidate for disk caching. It has a small number of variations, and its content is determined by a small number of parameters.
Determining how to cache the body pagelet is more complex. The contents of the body pagelet probably depend on where the website visitor is in the site. There are three possible types of content for the body pagelet:
The results of a search that the website visitor runs
The results of a frequently run query
Your caching strategy should be as follows:
If the content of the body pagelet is the result of a search based on parameters that the website visitor enters, you do not want to cache it. Such pages change for each visitor, and there is little benefit to caching them.
If the content is the product of a standard query that visitors often use, you should use resultset caching. Caching frequently run queries in the memory cache improves performance. For more information on resultset caching, see Chapter 14, "Resultset Caching and Queries."
If the content of the body pagelet is the text of an article, you should cache the pagelet to disk.
The values in the cscacheinfo field of the
SiteCatalog table allow you to control how pages get cached on WebCenter Sites on a page-by-page basis.
You can change these properties for each page and pagelet in your website. For example, if you want a containing page element to be uncached on WebCenter Sites, set the values in
For more information on the cscacheinfo field, see Section 23.4, "Creating Template Assets."
To implement double-buffered caching, you code your elements with Satellite Server tags. If you are running WebCenter Sites and Satellite Server only, use the Satellite tags documented in the Satellite Server sections of the Oracle Fusion Middleware WebCenter Sites Tag Reference.
Automatic cache maintenance is dependent upon logging your assets in the cache tracking tables. If you use the
ASSET.LOAD tag to load an asset, that asset is automatically logged in the cache tracking tables. For those sections where
ASSET.LOAD is not used, use the
RENDER.LOGDEP tag to log content in the cache tracking tables.
Cache dependencies are logged only if a page or pagelet is cached on WebCenter Sites. If a page is uncached on WebCenter Sites but cached on Satellite Server, that page will not be automatically flushed from the cache when its content is updated.
Cached pagelets require special security considerations as you design your site and develop your caching strategy. The following sections outline security considerations for pages cached in the WebCenter Sites and Satellite Server caches.
Pagelets that are disk cached on WebCenter Sites are bound by WebCenter Sites's ACLs, allowing you to use those ACLs to prevent unauthorized access to a page.
Note, however, that although WebCenter Sites checks the ACL of a containing page, it does not check the ACLs of the pagelets that the containing page calls. For example, suppose that your site uses three ACLs:
TopSecret. Your containing page can be viewed by members of the
Open ACL, but it calls pagelets that should be viewed only by members of the
TopSecret ACLs. Because WebCenter Sites only checks a visitor's ACL of the containing page, visitors with the
Open ACL can view content meant for members of the
Include the ACL for the page that you want to protect in that page's cache criteria, as shown in the following sample code:
<render.satellitepage pagename="innerwrapper" userAcl="SessionVariables.member" c="Article" cid="123">
In the pagelet, insert code to check the ACLs, as shown in the following sample:
<asset.load name="art" type="Variables.c" OBJECTID="Variables.cid"/> <ASSET.GET NAME="art" FIELD="myACL"/> <!-- note you need a column in your db to support this --> <IF COND="Variables.userACL=Variables.myACL"> <THEN> <render.satellitepage pagename="protected_art_tmpl1" c="Variables.c" cid="Variables.cid"/> </THEN> <ELSE> <render.satellitepage pagename="accessDenied"/> </ELSE> </IF>
Pagelets that will be cached on Satellite Server are bound only by WebCenter Sites ACLs under the following circumstances:
If they are retrieved from the WebCenter Sites cache
If they must be generated by WebCenter Sites to fulfill the page request
If a pagelet is served from the Satellite Server cache, it is no longer protected by WebCenter Sites ACLs.
To ensure that the content of your Satellite Server pages is secure, never cache your containing page and be sure that you put an ACL checking mechanism in the uncached container.
If your elements are coded with Satellite tags but you do not yet have
Satellite Server installed, the page design considerations outlined in Section 126.96.36.199, "WebCenter Sites Security" apply to you. Once Satellite Server is installed, however, WebCenter Sites checks the ACLs of uncached pagelets called from a containing page. The ACLs of pagelets cached on Satellite Server are not checked.