Understanding the Assets in WebCenter Sites
By Kadmin, Aug 25, 2018
An asset is defined as: “An object that stored in the WCS database that can be created, edited, inspected, deleted, duplicated, placed into workflow, tracked through revision tracking, searched for, and published for delivery to your site.” – Oracle WebCenter Sites Developers Guide Assets themselves perform one of three roles in WCS. They are: 1. Provide Content – To be read (or otherwise consumed) by website visitors. 2. Provide Formatting – The behind the scenes code upon which the content sits. 3. Provide Structure – The scaffolding for storing content in the WCS database. Now this is starting to narrow the definition of what an asset is. As a developer my goal is to design asset types that make it easy for content contributors to work, while simultaneously being efficiently rendered for site visitors to view. See how this balancing act works? Happy contributors and happy users. The only thing that stands between these two worlds is a bunch of assets. In WCS assets can fall into one of two data models. Basic Assets: Basic assets have one primary storage table and basic parent-child relationships with each other. These stand alone assets can be an article, a picture, a query, etc. Or, the more complex and mysterious: Flex Assets: Flex assets can stretch across multiple database tables, have many more fields than basic assets, and can inherit attribute values from a family tree that resembles the Houses of Lancaster and York circa 1399 – 1485AD. The bottom line is you can do a lot with these families of assets. WebCenter Sites contains the following asset types: 1. Query – Query assets are used to retrieve a list of data based on your specifications. These can be used in page assets, collections, or recommendations. 2. Collections – Collections are built from one or more queries and store an ordered list of assets of one type. 3. Page – A page stores references to other asset types and is how you visually represent your site. 4. Template – Template represent the building blocks that make up pages and pagelets. 5. CSElement – CSElements are used for code that you want to share across more than one template, but they don’t render assets themselves. 6. SiteEntry – These represent a WCS page or pagelet and has CSElement assigned as the root element to generate the page. 7. Attribute Editor – An editor that specifies how data is entered for a flex attribute when that attribute is displayed. It was quick overview of some of the assets included in WCS and what they are used for.
Caching In WebCenter Sites
By Kadmin, Aug 28, 2018
Caching has few different types and applies to different application layers. These are the following:
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 that query 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, all corresponding resultsets are flushed. Using the Support Tools, it is possible to inspect a graphic representation of the contents of the Resultset cache, including which resultsets are full, and the percentage of queries that are hitting (or missing) the cache. The idea is to maximise the number of queries that hit the cache, and to size the caches big enough that the maximum is rarely reached. Satellite Server Cache All initial requests to a Content Server installation should (ideally) hit the Satellite servlet first. If they don’t, you’re probably doing something wrong. Satellite Server has no database and most of the contents of 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 the ContentServer and BlobServer servlets. Pagelets are smallish parts of a page which are subsequently turned by Satellite Server into an entire webpage. 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 the tiny fragments. Generally you’ll 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 Templates and 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 not recommended. 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 work around 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 of caching 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 is necessary 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 is invalidated.
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. 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 your system, particularly the database. If you think of the application stack as a funnel, a good caching strategy will ensure that the vast majority of 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 very few would be reaching all the way to the database.