WebCenter Sites Caching Strategies

This post is going to introduce you to the basic concepts of caching in WebCenter Sites as well as some slightly 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 most important. It can mean the difference between a site that’s lightning fast, and one that crawls, or can’t handle your user or editorial traffic.

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

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 that query 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, all corresponding resultsets are flushed.

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

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

Satellite Server Cache

All initial requests to a Content Server installation should (ideally) hit the Satellite servlet first. If they don’t, you’re probably doing something wrong. Satellite Server has no database and most of the contents of 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 the ContentServer and BlobServer servlets. Pagelets are smallish parts of a page which are subsequently turned by Satellite Server into an entire webpage.

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 the tiny fragments. Generally you’ll 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 Templates and 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 not recommended. It is more expensive than using the extra layer of caching that Satellite Server provides.

InCache

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 work around 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 of caching 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 is necessary 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 is invalidated.

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 AssetDataManager.read Java method, or the REST API.

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 your system, particularly the database.

If you think of the application stack as a funnel, a good caching strategy will ensure that the vast majority of 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 very few would be reaching all the way to the database.