Posts Tagged ‘Caching’

I thought of discussing about the CacheManager. But, First of all, before discussing the CacheManager of Content Server, we have to discuss what is the purpose of caching a website. There is a great prominence for Caching in Web Content Management. What ever the CMS is used, if we cache the website, the performance of the site will be drastically improved.

What happens if we don’t enable caching for a website / page:

  1. When ever a visitor of a site hits on the url, say, the call will go to the web server, and from the web server to the content server, and then from content server to the database. And the response will travel in the reverse direction. Finally the output is rendered. All this process will take a long time (as compared to that of cached site).
  2. The overall site loading time will be high.
  3. Page loading time is obviously high.
  4. As the number of calls to content server and the database are high, the performance of the overall system will be affected.
  5. Finally, the business will be affected.

What happens if we enable caching for  a website / page:

  1. When the user hits the url, the page will be directly served from the cache, instead of making several calls to the content server and database.
  2. The performance of entire website is good, as the page load time is short.
  3. The overall target of the business can be easily achieved.

What happens if we don’t follow proper caching techniques:

  1. The updated content (whenever updated by the content authors) will not reflect the production site properly.
  2. Outdated content will be served by the server.
  3. As a result, the visitor of the site receives false and outdated information.

This is the prominence of caching. So, proper Caching techniques should be followed in order to achieve the target of creating a good site.

In future, we will concentrate more on caching…so… stay tuned…

Following are some of the important properties related to PAGE CACHING in FUTURETENSE.INI file.

  1. cs.nocache
  2. cs.pgCacheTimeout
  3. cc.SystemPageCacheCSz
  4. cc.SystemPageCacheTimeout
  5. cs.alwaysusedisk
  6. cs.freezeCache
  7. 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 pages out from the cache.

Sites that use intelligent page  cache invalidation through CacheManager, including CS Direct sites written 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 zero when Satellite Server is used can result in pages that cannot be ever be explicitly removed from the Satellite Server cache.


This is the maximum number of pages that will be cached in memory.  Pages will still be cached to the database but for better performance pages should be cached to memory too.  This property allows you to specify how many pages will live in memory.  Default value is 10,000, reduce if memory is at a premium.  Performance may suffer.


This is the default lifetime of a cached page in memory.  Cached pages will live in the database until they are set to expire but for performance reasons pages are also cached in memory.  This specifies the timeout (minutes) of the memory cache.  If memory is at a premium you may shrink this value but it is set to 24 hours (1440 minutes) by default.


This specifies the default behavior for page entries in the site catalog that have no specific cache override property. If set to yes, then pages served from the Content Server will be cached unless explicitly specified otherwise in cacheinfo. Though the name indicates that pages are cached to disk, they are in fact cached to the database using url-columns.

Legal values are yes and no.


This controls whether Content Server expires cached pages on a schedule.  Specify yes to prevent the creation of an event to periodically clear the page cache.  No pages whose expiry date has passed will ever be served regardless of this property value because their expiration is checked immediately prior to serving.

Legal values are yes and no.


This property specifies whether or not blob dependencies will be flushed from the inventory (SystemItemCache table) when the blob times out from cache.

If set to true, then blob inventory items will not be cleared from the inventory table.  This improves the reliability of CacheManager such that blobs can be flushed from SatelliteServer when the blobs have expired from ContentServer.  The cost is increased use of space in the database.  If set to false, then  when a blob expires from the cache, the corresponding inventory entries will also be removed from the database.  If the cache is being actively managed, the blobs should not ever expire from the cache.

The default value is false.

While building a website (Either by a WCM or normal html, etc), there will be certain images or other assets which seldom change, like Company Logo, etc. Say for example, CompanyLogo.png.

As we know, the images (even pdfs, etc) are nothing but blobs in Fatwire / Oracle WebCenter Sites.

The performance of the over all site can be improved by changing the way of serving these NEVER-EXPIRING BLOBS. The never expiring images / blobs which we discussed above in the first paragraph, need not be called from Satellite Server Cache / Content Server Cache. If we use an alternative method, the performance can be improved, as the number of calls have been reduced.

Follow the below mechanism for serving the NEVER-EXPIRING BLOBS in Fatwire / Oracle WebCenter Sites.

  1. Copy those Never-Expiring Blobs to your Satellite Server hosts. Place them under the doc root for your web server.
  2. In the code, instead of the satellite:blob tags, use <img src=”…”> tag to access the blob placed on your Satellite Server.

NOTE: While using this mechanism for serving never-expiring blobs, make sure that you place those blobs (ex: images) in all the Satellite Server host locations. If the blob is not present in any of the location, the Satellite Server cannot warn you that one of the Satellite Server hosts does not contain the same blob, that is contained in other hosts.


Caching is one of the most powerful techniques of Fatwire. An efficient caching system improves the performance of the overall system performance, by reducing the un-necessary overload to the Content server, and as well as the web server.

1. The Content server caches the pages that available in the CS system.

2. The Co-Resident Satellite server provides a second level of caching for the CS.

3. The Remote Satellite server provides another level of caching, so that the content can be closer to the intended audience.

Double – Buffered Caching:

When assets are updated and published, the Content Server 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 updatedassets.
  • CacheManager flushes the outdated Pages from the Content Server cache, then reloads the Content Server cache with the updated Pages.
  • CacheManager flushes the outdated items from the Satellite Server cache. As visitors come to the web site and request a page P1, the Satellite Server searches to see if page P1 is in its cache. Because P1 is not in the Satellite Server cache, the request is passed
    on to Content Server.
  • The Satellite Server system’s cache is filled with an updated version of page P1, taken from the Content Server cache. The updated page is served to the requestors. If pageP1 were requested again, the page would be served from the Satellite Server cache.

Hence, this Caching system involves both Content Server Caching and Satellite server Caching.