Should Remote Satellite Server be used for Edge Caching?
Lately, I have come across a few clients wanting to use WebCenter Sites Remote Satellite Server (rSS) as an edge cache – to cache content closer to the end client. Typical pattern is the client wants to have WebCenter Sites delivery servers in a data center in US and serve the Asia Pacific traffic using Remote Satellite Server in Asia/Pacific. The client wants to know if this is a good practice.
Well the short answer is no, this is not a good architecture design, and it’s against the best practices. Let’s look at the reasons why I say this is not a good architecture design.
WebCenter Sites, in addition to being a Web Experience & Content Management system is also a caching engine. It drives its performance by using a number of different layers of caching, including Page Caching[1]. Page Caching is also done at two different layers – WebCenter Sites Servers and then on Remote Satellite Servers.
To get the best out of Page Caching, the page is broken into a few modular pagelets – like header, footer, navigation, and center body. Each pagelet is cached separately. [2],[3],[4] Usually, there is an uncached wrapper. The uncached wrapper has logic for reading cookies, authentication, authorization, set user profile, and other logic that cannot be cached. [5]
The cached pagelets can reside both in Remote Satellite Server and WebCenter Sites server. When a site visitor sends a HTTP request to view a page, the request first goes to Remote Satellite Server. Remote Satellite Server checks if the pagelets to construct the page are in its cache or not. If a pagelet is not in its cache, Remote Satellite Server sends a request to WebCenter Sites Server to get the pagelet. If there is any uncached pagelet, the code to generate HTML for that pagelet is executed on WebCenter Sites server. Thus to serve a single request to view a page, rSS may need to send multiple requests to WebCenter Sites server, making the communication between rSS and WebCenter Sites Server very chatty. If rSS is physically very far from WebCenter Sites and the band-width between them is not very high, it adversely affects the page load time.
To get reasonable performance if rSS and WebCenter Sites servers are very far apart – say in different continents – is to cache the whole page. This requires that there is no uncached wrapper, that the number of pagelets is very few – say 1 or 2. Since the whole page is cached, the request can be satisfied by rSS and no request needs to be sent from rSS to WebCenter Sites Server.
Although this may look like a reasonable approach, in practice it will not work for most of the clients. Caching the whole page causes the page to have a very high number of dependencies. A Navigation pagelet itself may have a few tens of asset dependencies. A list of “Top Ten Articles” may have another ten asset dependencies. A home page may have several tens or hundreds of asset dependencies. Whenever we publish an asset, WebCenter Sites flushes all the dependent cached pages.
Additionally, if there is any “unknown” dependency[6], it may cause even a greater number of pages to be flushed from cache. Unknown dependencies are introduced when there is no way to predict the set of assets needed to compose a web page – say pages that require search, or use WebCenter Sites Search State tags. If there is an unknown dependency on a page, the page is flushed every time an asset of the asset type is published.
This means any publish is likely to flush a large number of pages from Remote Satellite Servers. So, in practice, to use Remote Satellite Server as a remote cache, and to cache the full pages require that the pages:
* should not have any logic that cannot be cached – like authentication, use of cookies, setting user profile data, integration with some back-end services etc.
* should not use unached wrapper, and cache the full page
* should limit the number of pagelets to very small say one or two
* should not use any tags that introduce unknown dependencies
* should not be using any functionality like WebCenter Sites Engage and Community Server
* publishing should be limited to one or two a day, that also during off peak hours for the Remote Satellite Servers
With so many limitations, I do not see how one can have a meaningful architecture with Remote Satellite Servers in different remote regions. An alternate architecture is to have WebCenter Sites delivery cluster in different regions and publish to them from central WebCenter Sites Management Servers.
[1] http://docs.oracle.com/cd/E29542_01/doc.1111/e29634/dev_codingelements.htm#WBCSD1997
[2] http://docs.oracle.com/cd/E29542_01/doc.1111/e29634/dev_caching_chapter.htm#WBCSD6074
[3] http://www.ateam-oracle.com/double-buffered-caching-with-incache-in-webcenter-sites-11gr1/
[4] http://www.ateam-oracle.com/sites-page-caching-remote-satelliteserver-round-trips-and-render-tags/
[5] http://www.ateam-oracle.com/how-to-prevent-overcaching-with-wc-sites/
[6] http://www.ateam-oracle.com/importance-of-wrapper-in-webcenter-sites11gr1/
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission