Caching WCS

  • View

  • Download

Embed Size (px)


Caching WCS

Text of Caching WCS

  • 5/19/2018 Caching WCS


    This post is going to introduce you to the basic concepts of caching inWebCenter Sitesas well as someslightly more advanced caching concepts.

    TL;DR With careful tuning of your WebCenter Sites caching strategy, you can dramatically increase the

    performance of your system.

    Of all the tasks you can undertake while designing a WCS implementation, caching is by far the mostimportant. It can mean the difference between a site thats lightning fast, and one that crawls, or cant

    handle your user or editorial traffic.

    Caching come in a few different flavours and applies to different application layers. These are thefollowing:

    Resultset Cache

    Content Server maintains a cache called the Resultset Cache which sits between the database and the

    CatalogManager servlet which governs database access.

    Content Server caches the resultsets in memory. The first time a query is executed, the results of thatquery are stored in memory. When the same query is ran, the results are served from memory rather than

    querying the database again.

    The Resultset Cache Settings are specified in the futuretense.ini configuration file and include:

    default number of resultsets to keep in memory

    default amount of time to keep resultsets in memory

    how to calculate the expiration time

    table-specific settings

    When the maximum is reached, the least recently used resultset is flushed. When a table is updated, allcorresponding resultsets are flushed.

    Using the Support Tools, it is possible to inspect a graphic representation of the contents of the Resultsetcache, including which resultsets are full, and the percentage of queries that are hitting (or missing) thecache.

    The idea is to maximise the number of queries that hit the cache, and to size the caches big enough thatthe maximum is rarely reached.

    Satellite Server Cache

    All initial requests to a Content Server installation should (ideally) hit the Satellite servlet first. If theydont, youre probably doing something wrong. Satellite Server has no database and most of the contentsof its cache will generally be held in memory, although this is configurable.

    In general, Satellite Server spends most of its time assembling pagelets and proxying requests to theContentServer and BlobServer servlets. Pagelets are smallish parts of a page which are subsequentlyturned by Satellite Server into an entire webpage.
  • 5/19/2018 Caching WCS


    There is an an ideal number of pagelets which compose a page.

    If there are too few, it can result in large swathes of the cache being invalidated during a publish.

    If there are too many, Satellite Server can end up spending large amounts of time putting together all thetiny fragments. Generally youll want no more than a couple of dozen pagelets in any given page.

    Content Server Cache

    Next up is the core Content Server cache. This executes the code from your CSElements and Templatesand from this generates and stores pagelets at the request of Satellite Server.

    Note that Satellite Server itself cannot generate the pagelets, it only assembles them. Note also that the

    caching parameters can be set separately on Content Server and Satellite Server.

    Content Server can also assemble pages without the assistance of Satellite Server, but this is notrecommended. It is more expensive than using the extra layer of caching that Satellite Server provides.


    Historically, the Content Server cache utilised the database and filesystem to store its cache fragments.

    These fragments were stored in a table called SystemPageCache, and on the filesystem in the location[shared_foler]/SystemPageCache.

    The issue with this was that that table could get big very quickly, and there are also three files stored on

    the filesystem for every entry in the table (the .qry, .hdr, and .txt files).

    The files are stored in nested, numbered directories, and can easily run into millions of files. To workaround the limitations with this system, InCache was developed.

    This system is built on top of Ehcache, a product from Terracotta. Compared to the legacy method ofcaching to the database, inCache offers improved website performance. This is because the cache is

    moved from the filesystem and database into memory.

    Naturally, this move can drastically increase the usage of the JVM heap, so careful sizing of the heap isnecessary when migrating from the old caching method to InCache.

    It is also decentralised as opposed to the older solution, so each Content Server instance in a cluster

    maintains its own cache, and invalidation messages are sent to each cluster node when a cache entry isinvalidated.

    Asset Cache

    This is a relative newcomer in the caching architecture, only becoming available with the 7.6 release of

    the product, because it is based on the InCache framework mentioned above.

    Rather than caching pagelets, it caches the results of loading an asset, for instance with the asset :load tag,the Java method, or the REST API.

  • 5/19/2018 Caching WCS


    It protects WebCenter Sites performance by taking up load that would otherwise affect the database.

    In Summary

    What all of these caches are working towards is to reduce the load on the various components of yoursystem, particularly the database.

    If you think of the application stack as a funnel, a good caching strategy will ensure that the vast majorityof the requests are dealt with at the upper levels of the stack.

    The Satellite Server cache should field most of the traffic, a few requests may be dealt with by the

    Content Server cache and Asset Cache, a small number might get as far as the resultset cache, and veryfew would be reaching all the way to the database.

    Flush the cache with a URL like this:


    If it worked, you should see a response like this: CacheServer flushing all pages.

    Trouble shooting tips.

    If flushing gives you this error: CacheServer : No access allowed for requested action.(Force pageflush), check the following.

    o Are you sure your username and password are correct?

    o Does that user name have SiteGod ACL?o Are you logged in?

    I made some changes and can't see them on refresh! Check your URL. If it is a satellite URL(http://DOMAIN/servlet/ Satellite), change Satelliteto ContentServer, i.e.http://DOMAIN/servlet/ContentServerand refresh again.

    CSElements called by SiteEntry- to cache or not to cache.o If it is static (like some non changing content or maybe a Javascript file), cache it. In the

    SiteEntry, set "Pagelet Cache Criteria" to "true,*".o If the element is dynamic, i.e. it performs some processing and the output should be

    different each time, don't cache it. In the SiteEntry, set "Pagelet Cache Criteria" to"false".

    o See CacheInfo String Syntaxsection of the developer pdf for a detailed description of

    how to use this setting.o I said don't cache, but it is! I found (CS 5.5) that when I set my SiteEntryinitially to

    "true,*" and changed it afterwards to "false", it was still being cached. To fix it, I deletedand re-created the SiteEntry.

    Explicitly Removing Entries from CacheIndividual entries can be removed 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 username, password and reset parameters), it is possible to flush all of the contents of theSatellite Server cache. It is not possible to flush individual entries using GET.

    Automatic RemovalAs described above, it is possible to flush the Satellite Server cache using CacheManager. As described,

  • 5/19/2018 Caching WCS


    CacheManager is only able to flush entries on Satellite Server if a corresponding object is cached onContent Server. This is the case because of the way Content Server tracks the contents of the Satellite

    Server cache.As described above, it is possible to flush the Satellite Server cache by using CacheManager, as long as acorresponding object is cached on Content Server. The corresponding object is required because of theway Content Server tracks the contents of the Satellite Server cache.

    Following are some of the important properties related to PAGE CACHINGin FUTURETENSE.INI


    1. cs.nocache2.

    cs.pgCacheTimeout3. cc.SystemPageCacheCSz

    4. cc.SystemPageCacheTimeout5. cs.alwaysusedisk

    6. cs.freezeCache7. cs.manage.expired.blob.inventory

    We will now have a detailed look about these properties.


    This forcibly disables the adding and serving of pages from cache. Legal values are true and false.


    This is the default lifetime of a cached page, specified in minutes. Specify 0 (zero) to never time pagesout from the cache.

    Sites that use intelligent page cache invalidation through CacheManager, including CS Direct siteswritten using CS Direct 4.0 coding practices and later, will be able to rely on automatic cache invalidation

    so timeout is not relevant.

    Only advanced users should modify the value of this property. Setting it to a value greater than zerowhen Satellite Server is used can result in pages that cannot be ever be explicitly removed from the