Home > Documents > Caching WCS

Caching WCS

Date post: 09-Oct-2015
Category:
Author: radha1990
View: 108 times
Download: 4 times
Share this document with a friend
Description:
Caching WCS
Embed Size (px)
Popular Tags:

of 16

Transcript
  • 5/19/2018 Caching WCS

    1/16

    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:

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

    table-specific settings

    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

    2/16

    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.

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

    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.

  • 5/19/2018 Caching WCS

    3/16

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

    http://DOMAIN/servlet/CacheServer?all=true&username=USERNAME&password=PASSWORD

    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.

    CSElements called by SiteEntry- to cache or not to cache.o If it is static (like some non changing content or maybe a Javascript file), cache it. In the

    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

    4/16

    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

    file.

    1. cs.nocache2.

    cs.pgCacheTimeout3. cc.SystemPageCacheCSz

    4. cc.SystemPageCacheTimeout5. cs.alwaysusedisk

    6. cs.freezeCache7. cs.manage.expired.blob.inventory

    We will now have a detailed look about these properties.

    cs.nocache

    This forcibly disables the adding and serving of pages from cache. Legal values are true and false.

    cs.pgCacheTimeout

    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

    Satellite Server cache.

    cc.SystemPageCacheCSz

    This is the maximum number of pages that will be cached in memory. Pages will still be cached to thedatabase 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 apremium. Performance may suffer.

    cc.SystemPageCacheTimeout

    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

  • 5/19/2018 Caching WCS

    5/16

    (minutes) of the memory cache. If memory is at a premium you may shrink this value but it is set to 24hours (1440 minutes) by default.

    cs.alwaysusedisk

    This specifies the default behavior for page entries in the site catalog that have no specific cache overrideproperty. If set to yes, then pages served from the Content Server will be cached unless explicitlyspecified 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.

    cs.freezeCache

    This controls whether Content Server expires cached pages on a schedule. Specify yes to prevent thecreation 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.

    cs.manage.expired.blob.inventory

    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 thereliability of CacheManager such that blobs can be flushed from SatelliteServer when the blobs haveexpired 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 thedatabase. If the cache is being actively managed, the blobs should not ever expire from the cache.

    The default value is false.

    The term PAGEconstitutes a very important concept in FATWIRE.

    There are a few terminologies in Fatwire related to Page, such as PAGE, PAGELET , PAGE NAME,

    PAGE ASSET.

    Really they are confusing. At least, Im very much confused with these terminologies in the beginning.

    We will discuss the basic differences between these terminologies, so that we will get some clear cut idea,and we will know when to use which term.

    1.PAGELET: A Pagelet is the result of an HTTP request. It is a piece of a rendered page. Its one among

    several pagelets that are rendered and displayed in a browser window. It has an associated element file,and that element has logic to generate this Pagelet. A pagelet can be cached in the Content Server andSatellite Server page caches.

  • 5/19/2018 Caching WCS

    6/16

    2.PAGE: A Page is nothing but the result of an HTTP request. It is the one which is displayed in abrowser window. Sometimes, a page is created by compiling several pagelets into one final, displayed or

    rendered page. It has an associated element file, and that element has logic to generate this page. A pagecan be cached in the Content Server and Satellite Server page caches.

    3. PAGE NAME:This is the complete name given to the page. For example, if Full is the name of a

    page, and if its type is Article, and if it is in the site Sample, the following will be the PAGE NAME:Sample/Article/Full.

    4. PAGE ASSET:A page asset is the one which simply act as containers for the actual content. These

    containers are arranged in the SITEPLAN tab of the TREE to facilitate the ease of navigation.Youassociate other content and other assets with these PAGE ASSETS and then you publish them.

    Caching in Fatwire

    Fatwire supports double-buffered caching.WebCenter Sites double-buffered page caching method usesthe WebCenter Sites and Satellite Server caches in tandem on live web sites. Double buffering ensuresthat pages are always kept in cache, either on WebCenter Sites or Satellite Server, to protect WebCenter

    Sites from an overload of page requests and prevent the live web site from displaying blank pages andbroken links.

    By default, WebCenter Sites and Satellite Server use inCache as their page caching framework.

    Satellite Server

    Satellite Server is a caching application. It supplements WebCenter Sites caching functionality by

    providing additional page caches.

    By default, co-resident Satellite Server is installed on the same machine where WebCenter Sites isinstalled. We can further improve our systems performance by installing Satellite Server remotely so it

    can cache pages and pagelets closer to their intended audience. Remote Satellite Server hosts are fast,inexpensive caches of WebCenter Sites pages. They reduce the load on the WebCenter Sites host,dramatically increase the speed of page delivery to your site visitors, and provide a simple and

    inexpensive way to scale our WebCenter Sites system.

    When the load balancer routes an HTTP request for a page to Satellite Server, Satellite Server eitherserves the page if the page is in its cache, or if the page is not cached, it

    forwards the HTTP request to WebCenter Sites.

    The basic chain of events is the following:

    1. Satellite Server checks its cache.2. What happens next depends on whether the page is in the Satellite Server cache:

    Page is in Satell i te Server Cache:

    1. Satellite Server serves the page to the visitors browser.

    2. In this case, Satellite Server does not have to forward the request to the WebCenter Sitesdatabase, thus reducing the load on the WebCenter Sites database.

  • 5/19/2018 Caching WCS

    7/16

    Page is Not in Satell ite Server Cache

    1.

    Satellite Server forwards the request to WebCenter Sites.2. If WebCenter Sites has the page in its cache, it returns the cached page to Satellite Server. If the

    page is not in the WebCenter Sites cache, WebCenter Sitesrenders the page, caches a copy, and sends the page to Satellite Server.

    3.

    Satellite Server then caches the page and serves it to the visitors browser. When requested again,the page will be served from the Satellite Server cache, which

    reduces the load on the WebCenter Sites database.

    Each Satellite Server application is independent of every other Satellite Server application. An individualSatellite Server application has the following characteristics: It maintains its own cache.

    Itcannot request pages or pagelets from another Satellite Server application. It can request pages orpagelets from only the WebCenter Sites core.

    Satellite Server Servlets:

    Satellite Server is made up of several servlets: one that caches and serves pages, and two that manage thecache:

    SatelliteCaches pages at the pagelet level. The Satellite XML or JSP tags in our elements indicatewhich pagelets should be cached, and they control various SatelliteServer settings.

    InventoryEnables us to examine the Satellite Server cache so we can obtain the information we need

    to manually flush individual pages or pagelets from the cache when necessary. FlushServerHandles all types of cache-flushing. FlushServer can either flush the entire cache, or can

    flush individual items from the cache.

    In Short Satellite server

    Caches pagelets instead of pages

    Its better for pages that change frequently

    What is InCache?

    Oracle WebCenter Sites and Satellite Server ship with a caching system called the inCache framework, or

    simply inCache. This system is built on top of Ehcache, an opensource, standards-based product from Terracotta. Compared to the legacy method of caching to thedatabase, inCache offers improved website performance.

    inCache is a high performance, memory-based page and asset caching system that eliminates the need tocache Oracle WebCenter Sites data in a central, shared repositoryand shared file system.inCache also supports asset caching, by default.

    The inCache framework offers the following benefits:

    High performance.

  • 5/19/2018 Caching WCS

    8/16

    Decentralized architecture. The inCache framework eliminates database caching and shareddisks.

    On-demand page evaluation and invalidation. Nodes validate and update their currently cachedcontent only when the content is requested.

    Failover and persistence. Nodes that are shut down retain data in their local caches and updatethemselves upon restart against a centrally managed record of invalidations.

    What is Page Caching?

    Page caching is implemented at the template level and is used to cache pages on the WebCenter Sites

    system. Page caching plays a significant role in system performance. Ifan element is not changed and it will generate the same page each time it is invoked, why makeWebCenter Sites process the element each time it is called? If the generated page is cached, it can be

    served much faster than it can if it must first be generated.

    WebCenter Sites alone (independently of Satellite Server) can separately cache each page or pagelet thatis identified by a page entry in the SiteCatalog table. We can mark the expiration date of any pagelet in

    the cache by specifying a value for that page entry in that table.

    Page caching is made especially effective by the addition of Satellite Server.

    Resultset Caching

    Resultset caching is another feature that can greatly enhance system performance. When the WebCenterSites database is queried by any mechanism, the WebCenter Sites

    application can cache the resultset that it returns. The WebCenter Sites application keeps track of everytable in the database; whenever a table is modified, it flushes all the

    resultsets that were cached for that table.

    Whenever the database is queried, WebCenter Sites serves a resultseteither a cached resultset or anuncached resultset. Resultset caching reduces the load on your database and improves the response timefor queries.

    Asset Caching

    Asset caching is a memory-based system that is built on the inCache framework to optimize theperformance of WebCenter Sites by taking up load that would otherwiseaffect the database. In WebCenter Sites, programmatic usage of assets consists of loading and renderingtheir attributes. Given that assets are loaded by templates, which are stored in the WebCenter Sitesdatabase, AssetCache is used only on WebCenter Sites nodes. Asset caching includes the AssetCache

    container component which functions by caching assets and interacting with existing inCache

    components.

    Understanding Fatwire Multiple Caches

    When it comes discussing the Fatwire cache, I notices very often some confusion in customer minds. Iam not very surprised of this, since Fatwire has multiple caches and their relation is pretty complex.

    http://www.sciabarra.com/fatwire/2012/04/22/understanding-fatwire-multiple-caches/http://www.sciabarra.com/fatwire/2012/04/22/understanding-fatwire-multiple-caches/http://www.sciabarra.com/fatwire/2012/04/22/understanding-fatwire-multiple-caches/
  • 5/19/2018 Caching WCS

    9/16

    In this post I will try to clarify the situation, giving an overview that explains (almost) all of the them. Iam 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 satelliteservers, 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. Apagelet 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).

  • 5/19/2018 Caching WCS

    10/16

    Pagelets are assembled in place by Satellite to build complete web pages. Note that because pagelets areexpected 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 Inventoryservlet (using the appropriateusername and password), and can be flushed using the FlushServerservlet.

    Content Server Pagelet Cache

    ContentServer generates pagelets on request of Satellite, executing template code (either JSP or XML). Italso 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 mustbe fast as well.

    ContentServer cache is the second cache in place. You can inspect the Content Server Cache looking atthe SystemPageCache database table and its attachments. The servlet to clean the content server cache isCacheServer.

    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 emptingContentServer 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 workswith 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 outputpagelet 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 orto 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.

  • 5/19/2018 Caching WCS

    11/16

    Loading them is expensive because a lot of database requests may be required (or at least once, that is byfar 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 reusingalready 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 JavaResultSets). 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 associatedto tables, so the cached results are valid until the underlying database table changes. The result set cacheis invalidated table by table whenever someone write in the database table from where content wasretrieved.

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

    CS cache, SS cache, Blob cache, RS cache:

    Webcenter Sites offers double buffered caching means caching at two different places co-resident satelliteserver(CS Cache) and remote satellite server (SS Cache). In reality whoever installs Fatwire will get the

    co-resident SS by default and installs at least one remote satellite server. Remote SS helps in speeddelivery of the pages and reduces the load to content server (CS). Along with this the traditional result setcache is also available to reduce the load on database. The queries to the db is cached and it serves therequest if the same table is not updated.

    So, what are all the object that can be cached?

    Blobs, entire page or a portion of the page. Portion of web page is called pagelet. Sites allows you tocontrol the pagelet that needs to be cached in satellite server and content server. All the cacheable objectswill be cached either in disk or memory depending on the size of the objects. Size can be set in satellite

    properties file which will allow the objects to store in disk. Smaller objects are retained in memory.

    When the content is dynamic and real time then there is no point in caching those pagelets for example,search results page. Also never expiring blobs likes logo image need not be cached. Put them in web

    server root folder and refer it in the page using simple html img src tag.

  • 5/19/2018 Caching WCS

    12/16

    Page request handling:

    Request comes to SS.

    SS cache serves the page/pagelet if available else request passed to CS cache

    CS cache serves the page/pagelet if available else checks in resultset cache.

    RS cache serves the resultset if available else db is queried and the resultset is cached,

    page/pagelet is cached in CS cache and then SS cache

    inCache: (from 7.6)

    inCache is based on opensource java caching framework that was introduced in Fatwire 7.6. It is optional.We can disable and continue with traditional caching mechanism. inCache works very well in clusteredenvironment where multiple nodes to update their cache independently. You can enable inCache for pageand asset individually.

    inCache consists of four different caches pageByQry (simply PageCache), AssetCache,dependencyRepository and notifier. Last two is common for page caching and asset caching.

  • 5/19/2018 Caching WCS

    13/16

    A. Page cache is loaded withpage details

    B. Asset cache is loaded with asset detailsC. Dependency cache logs the dependency of the page/assetD. Notifier receives the page/asset invalidation and communicates to the cluster nodes.

    Cache will be flushed when:

    asset is updated / published

    assets expiration time (based on the property files) reaches

    using FlushServer servlet (Inventory servlet is used to inspect the cache)

    Cachingis always a broad topic in any design. Every CMS/Framework provides its own ways toimplement cache. I am using Fatwire 7 CMS. Fatwire provide 2 level of caching:

    1. Content Server Cache (CSCache)2. Satellite Server Cache (SSCache)

    Note:I will use CS and SS for Content Server and Satellite Server.

    Lets have a look how fatwire serve a request:

  • 5/19/2018 Caching WCS

    14/16

    Every time a user (End user) hit a page (A), the request goes to SSSS check if the requested page/pagelete is available in its cache. If the requested page/pagelate isavailable in SS cache, then it servers the requested page back to end user (E,F) otherwise SSrequest CS to provide it the requested page/pagelete (C)CS check if the requested page/pagelete is available in its cache. If the requested page/pagelate isavailable in CS cache, then it servers the requested page back to SS (D) otherwise CS follow the

    following steps:o CS process the code (Templates/CSElements) to generate the requested page/pagelete.

    o Cache* the page/pagelete on CS

    o Return the output to SS (D)

    Now, SS cache* the processed page/pagelete and return the complete page back to requested user

    (E,F)

    *Its not necessary that we cache every page/pagelete. If a page is cached but its internally callingnumber of uncached Elements (CSElements/Templates) then the cached page save the call for that

    element instead of html output. So every time a user request for a page, these uncached elements will gotevaluated on CS.

    Understanding cache dependencies

    WC Sites (formerly Fatwire ContentServer) is a content oriented CMS, as opposed to otherpage oriented

    CMS. The exact meaning ofbeing driven by the contentis thatyou are required only to describe yourcontent 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 andcode a WCS implementation.

    The biggest problem in this separation is thatyou must keep some track of the relation beetween yourcontent 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).

    http://www.sciabarra.com/fatwire/2012/06/05/understanding-cache-dependencies/http://www.sciabarra.com/fatwire/2012/06/05/understanding-cache-dependencies/http://mkbansal.files.wordpress.com/2010/06/cache1.jpghttp://www.sciabarra.com/fatwire/2012/06/05/understanding-cache-dependencies/
  • 5/19/2018 Caching WCS

    15/16

    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 usuallyjust once, but on the site the same article can appear a number of

    timesin 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 orjust as a simple link in many others.

    All those occurrencies appears in different web pages, and you have to update all of themwhen the

    underlying content model changes. For this reason WCS stores in the database dependencyinformations.

    The main reason to keep those informations is because they are needed for an easy and efficient updatingof 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 dependentpagelets are invalidated and regenerated.

    In practice

    You can see all of this in action simply inspecting the table SystemItemCache. This table is somewhatobscure but it keeps one of the more important informations used in publishing: dependencies betweenassets and pagelets.

    This table is calculated while rendering the content model in an actual live site. Many dependencies areactually calculated by the render:calltemplate. When you call a template, you are also declaring that anew pagelet (the one that will be rendered by the template you are invoking) will depend on the asset

    specified by cand cid. So a new dependency will be recorded for this asset.

    Dependencies can also be recorded explicitly using the render:logdeptag. Indeed, you may notice thatwhen 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 codegenerating 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 alsorequired).

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

  • 5/19/2018 Caching WCS

    16/16

    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 thecache).


Recommended