Caching your web pages can improve your site's performance. Whether your site is static or dynamic, you should design your site so that part or all of a given page is cached.
A modular page design is composed of multiple elements. It has several benefits such as improved system performance and reusability of common design elements.
Improved system performance, allowing you to develop an efficient caching strategy.
Common design elements, like navigation bars, may be coded once and used on multiple web pages.
This figure shows a simple modular page:
Figure 38-1 Modular Page
Each rectangle represents the generated output of one or more elements, referred to as a pagelet. These pagelets are called by a containing page, which allows you to do the following:
Lay out how the pagelets appear on the finished page.
Define code that must be evaluated each time the page is viewed, such as custom Access Control List (ACL) checking code.
This strategy lets you code an element once and use it in many places in your website.
WebCenter Sites allows you to cache entire web pages and the components that make up those web pages. An efficient page caching strategy helps you improve system performance by reducing load.
Two members of the WebCenter Sites product family implement page caching:
WebCenter Sites caches pages on the WebCenter Sites system.
Satellite Server 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 uses both the WebCenter Sites and Satellite Server caches to create an efficient caching strategy.
It speeds processing when 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, use one of the following tags:
Table 38-1 Caching Tags
|JSP Tag||XML Tag|
If the pagelet that you want to cache is not in the disk cache already, ContentServer adds it to the cache and then serves the pagelet.
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 several blobs.
WebCenter Sites offers a special servlet called BlobServer. The BlobServer gathers a blob from a table and performs all relevant security checks.
You can access BlobServer with the BlobServer tags:
Both of these tags cache blobs in the WebCenter Sites and Satellite Server caches. See Tag Reference for Oracle WebCenter Sites.
Deleting Blobs from the WebCenter Sites Memory Cache
To delete a specific blob from the WebCenter Sites cache, you must edit 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 it to
Satellite Server is automatically installed with WebCenter Sites, and provides an additional layer of caching. To improve your WebCenter Sites system's performance, you can add remote Satellite Server systems, placing 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 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. See Managing Satellite Server JSON File Properties in Property Files Reference for Oracle WebCenter Sites.
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.
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. See CacheInfo String Syntax in Using Advanced Page Caching Techniques.
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 discouraged because it can lead to unpredictable 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 according to 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 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 Satellite Server Properties.
This topic describes how the Satellite servlet caches web pages and how to implement caching with the Satellite servlet in tandem with modular page design to create a fast, efficient website.
How the Satellite Servlet Caches Pages
The Satellite servlet allows caching at the pagelet level. To implement caching with the Satellite servlet, use Satellite Server XML or JSP tags in your WebCenter Sites pages, and 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. This figure shows that this page is composed of a containing page and three pagelets; A, B, and C. The containing page and pagelets A and B are cached on a Satellite Server system, but pagelet C is not cached:
Figure 38-2 Web Page Named myPage
The following occurs 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 that 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.
Implementing Caching with the Satellite Servlet
To implement pagelet-level caching with the Satellite servlet, 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 host name 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.
Caching a Pagelet
The following sample code uses the
render:satellitepage tag to call a pagelet. If the pagelet is not 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 is 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. Nested pagelets are 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 unexpected 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 determines 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>
Caching a Blob
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 and a pagelet.
<html> <body> <!-- NOTE: This will fail if list has no content (== null) --> <ics:setvar name="category" value="logo"/> <ics:setvar name="errno" VALUE="0"/> <ics:selectto from="SmokeImage" list="imagelist" where="category" limit="1"/> <ics:then> <!-- 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" /> </ics:then> <render:satellitepage pagename="QA/Satellite/Functional/xml/"pagelet1"cachecontrol="never"/> </body> </html>
The following actions are defined in the above code:
ics:selectto tag performs a simple SQL query that retrieves a blob from the database. Results are returned in the form of an
satellite:blob tag loads the blob that was retrieved from the database. As with the
satellite.page tag, if the blob is not in Satellite's cache, Satellite loads and caches the blob. The
cachecontrol parameter is set so that the blob expires at a given time; in this case, every 30 minutes.
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. See Property Files Reference for Oracle WebCenter Sites.
The Inventory servlet lets you view the various items stored in the cache. You invoke the Inventory servlet by using the following URL:
where parameters are as defined in this table:
Table 38-2 Inventory Servlet Parameters
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 want the Inventory servlet to display. Valid values are:
If you do not supply the
The header contains the information types defined in this table:
Table 38-3 Information Types
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 CacheManager object maintains both the WebCenter Sites and Satellite Server caches. CacheManager can perform the following functions:
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 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.
The WebCenter Sites
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.
Items stored in the WebCenter Sites and Satellite Server caches are assigned 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 pagename, resargs, and pagecriteria fields of the
SiteCatalog table, and other internal data.
You can 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 that uses the values
blue in the
myPage cache key, enter the following:
favoritecolor,second_favoritecolor in the pagecriteria column
favoritecolor=red&second_favoritecolor=blue in 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 is 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 by the URL override values set in
pagecriteria. For example, you have the
pagecriteria set to
If the URL passes a value of
red,blue) will go into
myPage's cache key.
If the URL passes values of
red,blue) will go into
myPage's cache key.
If the URL passes 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 by a URL override values specified in the resargs fields.
The default cache settings for WebCenter Sites and Satellite Server are contained in the
wcs_properties.json file. These properties can be modified using the Property Management Tool. See the Property Files Reference for Oracle WebCenter Sites.
Additional Satellite Server properties are contained in the
wcs_properties.json file for remote Satellite Servers, located under the
config directory, and must be modified manually.
The following properties in
wcs_properties.json control disk caching:
cs.freezeCache: Controls whether the cache pruning thread should run to remove expired entries from the cache.
cs.nocache: Disables the entire page cache.
Satellite Server has two sets of properties in the
wcs_properties.json file (see the Property Files Reference for Oracle WebCenter Sites).
One property in the
wcs_properties.json file is categorized under Cache:
satellite.blob.cachecontrol.default, which specifies a default value for the
cachecontrol parameter for the
RENDER.SATELLITEBLOB tags and their JSP equivalents.
The other properties in the
wcs_properties.json file are categorized under Satellite:
cache_folder: Specifies the directory into which Satellite Server caches pagelets to disk.
file_size: Separates disk-cached pagelets and blobs from memory-cached pagelets and blobs, according to size.
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 defines when expired objects are pruned from cache.
cache_max: Specifies the maximum number of objects (pagelets and blobs) that can be cached in both memory cache and disk cache combined at a time.
WebCenter Sites and Oracle WebCenter Sites: Engage implement a double-buffered caching strategy. This caching uses the WebCenter Sites and Satellite Server caches in tandem. The double-buffered caching strategy ensures that pages are always kept in cache.
You can implement a similar caching strategy by using the CacheManager Java API. This only applies if you are if you are running the WebCenter Sites core and Satellite Server without any of the other CS modules or products. For more information about the CacheManager Java API, see Java API Reference for Oracle WebCenter Sites.
Both the WebCenter Sites core and Satellite Server caches are maintained by the WebCenter Sites 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 order shown in this figure:
Figure 38-3 Order of Cache Flushing 1
In the following figure, 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.
Figure 38-4 Order of Cache Flushing 2
In the following figure, CacheManager flushes the outdated
Page1 from the WebCenter Sites cache, then reloads the WebCenter Sites cache with the updated
Page1. 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.
Figure 38-5 Order of Cache Flushing 3
In the following figure, 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.
Figure 38-6 Order of Cache Flushing 4
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 is requested again, the page is 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 About 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.
This table summarizes the guidelines for caching pagelets:
Table 38-4 Guidelines for Caching Pagelets
|Cache a Pagelet||Don't Cache a Pagelet|
An example of a modular page is shown in this figure:
Figure 38-7 Modular Page
The containing page should never be cached. You can put logic that requires evaluation by WebCenter Sites into your pages, while still gaining the performance benefits of caching. Your page can also be protected by WebCenter Sites ACLs.
The header and footer pagelets in this example should be disk cached. They rarely get 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 may 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 consider the following points:
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. See Working with 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 are cached on WebCenter Sites.
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 cscacheinfo to
For more information about the cscacheinfo field, see Creating Template Assets.
To implement double-buffered caching, 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 Tag Reference for Oracle WebCenter Sites.
Automatic cache maintenance depends on you 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 is not 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 the WebCenter Sites 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
To ensure that all the relevant ACLs are checked:
<render.satellitepage pagename="innerwrapper" userAcl="SessionVariables.member" c="Article" cid="123">
<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 to be cached on Satellite Server are only bound 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 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.