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.
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.
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:
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.
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.
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.
