7.8.0 delivery tier improvements
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.
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.
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.
- Within the sitemap, it is now possible to configure a different component configuration id (typically a different rendering page) for different document types, allowing you to more easily mix multiple content types in the same folder. More documentation here.
- Several smaller improvements have been made to facilitate the creation of lightboxes. More documentation here.
- Many documentation updates:
- How to create a HST componentRenderingURL
- The HstRequestContext object
- How to add custom jcr event listener through Spring configuration
- Best practices on where to store assets
- How to do post-processing of a matched sitemap item using sitemapitem handlers
- How to search next to documents also in assets or gallery in a HstComponent class