Understanding cache dependencies
WC Sites  (formerly Fatwire ContentServer) is a content oriented CMS, as opposed to other page oriented CMS. The exact meaning of being driven by the content is that you are required only to describe your content without considering how this content will be actually rendered .

This idea has a few consequencies that must be taken in appropriate consideration when you design and code a WCS implementation.

The biggest problem in this separation is that you must keep some track of the relation beetween your content  and its rendering.

(Well this is not actually totally true, considering insite editing, that is a presentation oriented technology, however it does not change the concept - content and presentation are separated but related).

The relation between presentation and content
To better explain the problem consider a generic content, let's say an article in your site.

On the CMS you want to add it usually just once, but on the site the same article can appear a number of times in different web pages, in different formats.

For example an article can be displayed as a full text in a web page, as a summary in another web page or just as a simple link in many others.

All those occurrencies appears in different web pages, and you have to update  all of them when the underlying content model changes. For this reason WCS stores in the database dependency informations.

The main reason to keep those informations is because they are needed for an easy and efficient updating of the cache when the content changes.  In fact, when the site is rendered, blocks of html  (conventionally called pagelet) are generated from the content model and usually cached.

For each of those  pagelet a dependency is generated and stored.

When the content model is changed all the stored dependencies are walked through and the dependent pagelets are invalidated and regenerated.

 In practice
You can see all of this in action simply inspecting the table SystemItemCache. This table is somewhat obscure but it keeps one of the more important informations used in publishing: dependencies between assets and pagelets.

This table is calculated while rendering the content model in an actual live site. Many dependencies  are actually calculated by the render:calltemplate. When you call a template, you are also declaring that a new pagelet (the one that will be rendered by the template you are invoking) will depend on the asset specified by c and cid. So a new dependency will be recorded for this asset.

Dependencies can also be recorded explicitly using the render:logdep tag. Indeed, you may notice that when you create a new template, some code involving a logdep is automatically added.

That code should NOT be removed: it is adding a dependency between the template itself (the code generating the pagelet) and the generated pagelet. Obviously, when you change the code generating the pagelet, that pagelet must be regenerated.

In general, a pagelet rendering a given asset (identified by c and cid) depends always on the asset itself (so a c:cid dependency is required) and the template that render it (so a Template:tid dependency is also required).

However things can became much more complex than this. There are other sources of dependencies: for example searchstate calls usually generate some dependencies, and an index gathered by a search can depend on so many assets that... an  "unknown dep" can be generated.

Those special dependencies basically invalidate each pagelet when any asset of a given type changes.

Common Errors
Unfortunately, caching and even worse dependency management are often misunderstood.

Some (untrained) developers are somewhat vaguely aware of the caching, but very often they completely ignore dependencies.

A common error is to create a template that depends on two or more assets (the first one being the c/cid, while the other is specified with extra parameters). Unfortunately, only the dependency specified by c/cid is actually recorded, so when the other asset change, the corresponding pagelet is NOT invalidated.

The net effect is a website that won't be updated when the content change (unless you invalidate all the cache).



Filed under: Tutorial No Comments
22
Apr
2012
Understanding Fatwire Multiple Caches
When it comes discussing the Fatwire cache,  I notices very often some confusion in customer minds. I am not very surprised of this, since  Fatwire has multiple caches and their relation is pretty complex.

In this post I will try to clarify the situation, giving  an overview that explains (almost) all of the them. I am omitting here the BlobServer cache for clarity.

The structure of the available caches is depicted  in the diagram below. Read on for an explanation.





Satellite Pagelet Cache
When you visit a Fatwire website, you normally access to one of the Satellite Servers.

In the diagram there is only one Satellite, but in a normal deployment you should have many satellite servers, ideally geographically distributed in net, and the possibly located close to your browsing location, internet-wise.

Satellite Servers are the ultimate cache in place. They cache the site, splitting web pages in pagelets. A pagelet is a piece of already rendered html. It is important to understand that a pagelet is not a whole webpage, but actually only a part of a page (think to the header, a summary, a generic block).

Pagelets are  assembled  in place by Satellite to build complete web pages. Note that because pagelets are expected to be small enough to be kept in memory, assembling of a page is expected to be very fast (no database is involved,  mostly of the cache is kept in-memory except bigger files are stored on the disk). Actually Satellite spools to disk pagelets larger than a given threshold (configurable in property files).

However Satellite does not have the ability to render templates, so when a pagelet expires or is invalidated, Satellite must grab the updated pagelet from  Content Server.

Satellite cache can be inspected using a specific tool, the Inventory servlet (using the appropriate username and password), and can be flushed using the FlushServer servlet.

Content Server Pagelet Cache
ContentServer generates pagelets on request of Satellite, executing template code (either JSP or XML). It also caches the output of the rendering, for 2 reasons:

First reason, Satellite is optional, and Content Server can run a  site without Satellite, and must do it efficiently.
Second reason , multiple Satellites can be  deployed, so you may need to serve the same pagelets more than once. Also a Satellite can crash, or another satellite be added, so serving pagelets must be fast as well.
ContentServer cache is  the second cache in place. You can inspect the Content Server Cache looking at the SystemPageCache database table and its attachments. The servlet to clean the content server cache is CacheServer.

Please note that when you inspect the ContentServer cache you will see the pagelets generated for satellite, however cached pagelet  for Satellite are stored in memory within satellite. So empting ContentServer cache won't clean also Satellite cache. If you want to clean also Satellite cache, that you have to do it manually.

A complete reset of the front-end cache involves both all the Satellite Servers and Content Servers.

InCache Asset Cache
So far we have seen caches that store  pagelets, that are fragments of rendered  html. Those caches works with templates having cache enabled.

However it is common to have some templates that cannot be cached. Typically this happens with certain templates that  always return a different rendering (for example, searches), and caching the output pagelet can is difficult and fundamentally pointless.

The most recent addition to the family of Fatwire caches is InCache, that basically caches the  underlying "pojos" used for rendering.  You may ask what those pojos are.

When you execute template code, you perform calls like  <asset:load  name="theAsset" ...> or <assetset:setasset  name="theAssetSet" ...> to load assets. Please note that "theAsset"  or "theAssetSet" are actually Java Objects (POJO  = Plain Old Java Objects) that will be used to render the content. Loading them is expensive because a lot of database requests may be required (or at least once, that is by far the slower operation).

Enabling InCache, those pojos are cached as well. So this cache helps to speed up the rendering of uncached templates. Indeed, the vast majority of the time is spent querying the database, and reusing already queried POJO helps a lot in speeding up also uncached templates. It also helps saving memory and reducing garbage collection.



ResultSet Cache
Last but not least, there is also the old and good cache of database queries. When you query a database, you store the result in a list in memory (in Fatwire they are generally IList, that caches the output of Java ResultSets). As long as no one accesses any more to the table from where the IList was generated, running the same query will produce the same result, so it may be cached.

Result Set cache is caching results of database queries for each query executed. ResultSet are associated to tables, so  the cached results are valid until the underlying database table changes. The result set cache is invalidated table by table whenever someone write in the database table from where content was retrieved.

This cache is helpful because ultimately all the content must be extracted by the database, but is is useful also when you write custom queries. It can be tuned editing futuretense.ini and flushed using CatalogManager servlet.