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:
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
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.http://manifesto.co.uk/fatwire-and-webcenter-sites/http://manifesto.co.uk/fatwire-and-webcenter-sites/http://manifesto.co.uk/fatwire-and-webcenter-sites/http://manifesto.co.uk/fatwire-and-webcenter-sites/
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.
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.
5/19/2018 Caching WCS
It protects WebCenter Sites performance by taking up load that would otherwise affect the database.
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.
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
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