7.8.0 delivery tier improvements - BloomReach Experience - Open Source CMS

7.8.0 delivery tier improvements

Page cache

Pages that are configured to be personalized for each visitor cannot be served from a reverse proxy cache such as Apache mod_cache, Squid or Varnish. Those pages have to be served by the delivery tier for each request. Also, for certain types of behavioral targeting, the targeting engine needs to track the pages a visitor requests to incrementally learn his or her interests.

To ensure the site remains responsive, a caching mechanism has been implemented in the delivery tier that is capable of serving thousands of pages per second. The engine has been designed to integrate seamlessly with the targeting engine.

The documentation for the page cache can be found here.

Asynchronous components

Certain components are visitor specific to such a degree that they are essentially not cacheable; for example a component that displays the three stores or office locations that are closest to the visitor, based on his current location. These types of components can be configured to be rendered not as part of the whole page, but through a separate, client side, asynchronous Ajax call. Another use case for this feature are those components that render data that is coming from external systems, such as Twitter or other feeds.

This means that the page itself can actually be served from the cache. The feature can also be used when not using targeting or when using a regular reverse proxy cache.

The documentation for asynchronous components can be found here.

Page diagnostics

To facilitate performance analysis during development, testing or even in production, it is now possible to enable page diagnostics. Using a simple switch in the console, page diagnostics become available that detail for each page how much time each component takes to render, how long queries take, etc.

The documentation for page diagnostics can be found here.

Canonical access to content

The HST now uses the canonical (non virtual) part of the repository to access its content. Instead of using virtual entry points using facetselects to filter for live or preview, we now use different site users for live and preview content and filter based on ACLs. This reduces memory consumption by the repository enormously.

Developers can now also use plain jcr queries and bind the jcr node results to HippoBeans without being forced to use the HstQuery. Plain jcr queries now return only live or preview hits without needing some extra live|preview constraint as this is now taken care of by ACLs. The HST handles whether the live or preview user is used by the mount that is used. A developer does not need to take care of that.

As part of this work, we have also introduced the authorization query in the repository which results in two more benefits:

  • As opposed to plain jackrabbit, hippo repository can instantly return correct total (authorized) number of hits for a (jcr) user. Note that instant authorized hits with correct instant total hit count is now really a key feature of Hippo Repository
  • Faceted navigation now returns correct counts based on the exact number of readable hits for current jcr user. In the past, the counts could deviate a bit from the actual number of results due to authorization.

Other improvements

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?