Performance

Concept

There are many ways to boost your website’s performance. The three main areas that you can work on are: infrastructure, server-side performance, and front-end performance.

• Infrastructure includes network, switches and hardware. In general, the faster, the better; either way, there is little iKnowBase or your iKnowBase application can do to help.
• Front-end performance is all about the resources that end up on the client, such as the HTML, CSS, JavaScript, and images. iKnowBase does not provide any tools for optimizing this, but instead referes to client tools built for this purpose.
• Server-side performance covers the processing spent on producing the content being served to the client.

iKnowBase provides mechanisms to monitor your website and to optimize server-side computation, i.e. the time it takes for the server to produce the content/web page. The chapters below describes those mechanisms.

Monitoring

The iKnowBase java-applications are built with run-time monitoring and visibility into performance metrics. These tools are mostly available under /ikb$console, which is documented in iKnowBase System Administration.

The documentation is brief, and you may need to click around a bit to familiarize yourself with the tools. Here are a few pointers, though:

• From /ikb$console, you may switch on a developer mode which gives quick access to a development toolbar on all page engine pages, as well as per-session logging.
• You controol both logging levels and logging targets from the console. There is a RingBuffer/Memory-target which allows for quick access to the last 5000 log entries throughout the system, and there is a Session-based memory target which allows access to the last 10 page requests.
• There are performance probes throughout the system, available under the Monitor-tab.
• There is an /ikb$runner-endpoint, which runs a single component and makes the logs for that component readily available.

Caching on the client

Significant performance can be gained by tuning different cache areas. These areas can be devided into two main sections:

1. Static shared resources
2. Application cache

Static shared resources (/ressurs)

Static shared resources deployed to the /ressurs-directory can be cached in web cache capable software and the user’s browser using Cache Control Directives. Cache Control Directives must be configured on the web server serving /ressurs-content or any other capable intermediate server between the web server and the client.

Cache Control Directives are documented in RFC 2616 and must be adjusted according to the customer’s needs, but the following directives are typically applicable as response directives:

• max-age=<number of seconds> (see RFC 2616, chapter 14.9.3)
• public (see RFC 2616, chapter 14.9.1)
• must-revalidate (see RFC 2616, chapter 14.9.4)

Apache Web Server can be configured as follows:

 #Cache all /ressurs-files for 15 minutes in shared cache for all users. Revalidate after 15 minutes is mandatory
 <LocationMatch "(?i)^/ressurs/.*$">
   Header set Cache-Control "max-age=900, public, must-revalidate"
 </LocationMatch>

Caching content from the content server (/Content)

HTTP Response cache directives to client based on client input

When accessing contents provided by ikbViewer Content Server, certain URL-options can be used to control the Cache Control Directives returned to the client. For supported options, see iKnowBase API Reference > Content Server > Download content.

An example where cache directives with URL-options is applicable, is when using images stored in the iKnowBase content store as part of a relatively static web layout. The image URL /Content/40028/SampleImage.jpg will not return any cache headers (unless intermediate servers are configured to override). To cache the image for 60 seconds, use /Content/40028/expires=60/SampleImage.jpg. This will return HTTP Response Header “Expires: <now + 60 seconds>”.

HTTP Response cache directives to client for autogenerated URLs to iKnowBase content

The ContentViewer will sometimes genereate URLs to content, such as images or documents stored in document attributes. Whenever the ContentViewer is capable of generating a URL with proper caching directives without loading more data from the database, it will.

Caching on the application server

The iKnowBase application can cache data in memory, in order to avoid much more expensive operations involving the database.

Metadata Cache

Metadata for the components used in iKnowBase will be automatically cached in memory by the server. The metadata cache is revalidated against the iKnowBase repository if more than 10 seconds has passed between last revalidation and the current request. Data is reloaded from iKnowBase repository if any change is detected.

Metadata cache is by default replicated to other application instances using the same database, schema and network multicast group.

An administrator can force a cache clearing by using /ikb$console.

Page engine content cache

In iKnowBase you can enable content caching for any portlet on any page. When content caching is enabled for a portlet, the server will store the result of the first execution of the portlet in memory, hereafter called the cache. When further requests are made to the same portlet, the server will go to the cache, avoiding the overhead incurred by producing the result over again.

Content caching is suitable for portlets which displays information that seldom changes or information that is not critical to present in “real-time”. You need a deep understanding of the usage patterns in order to configure content caching appropriate. Beware that the content cache consumes memory. But, it also frees up resources by reducing the number of request to the server and server processing.

An administrator can force a cache clearing by using ikb$console or restarting the application/jvm.

Configure content caching

You configure caching per page component (a portlet living on a page). You may choose between four predefined content cache strategies as well as add your own definitions using Development Studio:

• Shared, 1 hour: The content of the portlet will be cached per domain and language; all users with the same language on the same domain will share the same cached content. The content will expire one hour after the first access.
• Shared, until next date: The content will be cached per domain and language; all users with the same language on the same domain will share the same cached content. The content will expire after midnight (server time).
• Per user, 1 hour: The content of the portlet will be cached per user, domain, and language. The content will expire one hour after the first access.
• Per user, until next date: The content of the portlet will be cached per user, domain, and language. The content will expire after midnight (server time).

When a portlet does not have content caching, it will most often be rendered with a portlet container, a set of div-tags surrounding the portlet; for some portlets (such as the content viewer), this can be specified as part of the portlet definition. For cached portlets, however, the decision whether to render a portlet container belongs to the page template. You must use the freemarker template RegionModel macro directive to specify whether to render a portlet container:

[@page.regions region="north" /]
[@page.regions region="north" container="true" /]
[@page.regions region="north" container="false" /]

Access control

Note that for a cached portlet, access control is applied when the content is first generated, and not when it is rendered. For example, if a portlet is set up with a shared content cache, the first user to access the portlet (before the content cache is populated) will generate the content, and subsequent users will see that exact content. Hence, if the portlet would generate more content to the first user than the next ones, due to security settings, the subsequent users would see more content than they should. You should therefor only use the shared cache when the content is public, or when all users who may access the portlet has access to the same data.

Refreshing the content cache

The content cache will be updated whenever a client requests the content of a cached portlet, and the time-to-live of the already cached content has expired. There is no way to have the server automatically detect and refresh the content outside of a client request.

Instant notifications of content cache updates

iKnowBase comes with client and server side support for creating applications with real time asynchronous messaging support, commonly referred to as iKnowBase Instant (see the chapter on this component for more information).

The iKnowBase PageEngine content cache has pre-built integration with iKnowBase Instant, covering the following basic areas:

• Publishing update notifications to iKnowBase Instant whenever content is regenerated.
• Rendering information that identifies the various cached portlets on a client page
• Using client side javascripts to listen for update notifications, reloading portlets that have been updated

The basic setup requirements are as follows:

• In Development Studio, you must create a “page cache strategy” with the flag "publish updates to instant"
• In your page, the relevant page components must be configured to used the new page cache strategy
• In your page template, the region in which the page components is rendered must be configured to render a portlet container
• Also in your page template, you must start the client script, ref the iKnowBase API Reference (but typically iKnowBase.PageEngine.InstantContentCache.start();)

Note that using instant notifications does come with a significant cost. Whenever there is a cache update of a portlet, all clients currently displaying that portlet (with the same cache key) will immediately request new content. If there are many clients listening, they will all generate requests at the same moment. While the cache infrastructure is quite fast, if the number of clients get too big, this may overload the system. This problem is severe enought that cache theory has given it it’s own name, “thundering herd”.

Setup

The content cache mechanism needs to be enabled for the site in order to use this functionality. By default, there is one shared content cache per database schema. This content cache is replicated between application servers running on the same subnet, using the same database schema. See the iKnowBase Installation Guide for further information.

Clustering and the application server cache

The application cache (JVM) will by default replicate to other application instances if they

• Share the same database name and schema (user)
• Support multicast network traffic (between the instances/servers)
• Configured with the same multicast group

A default multicast group is configured in the application, but can be changed by an administrator. See iKnowBase Installation Guide > Configuring the ikbViewer application > CacheManagerConfiguration for options.

Render Strategy

In iKnowBase you must specify a render strategy for a portlet on a page. The render strategy decides when to produce and render the portlet. This is a simple mechanism which enable you to delay the production and rendering of certain parts of a page, which enable quick rendering of the most critical parts of a page.

You can choose between three different render strategies:

• Inline: The portlet will be loaded and rendered by the browser together with the page.
• On load: The portlet will be loaded and rendered after the page is rendered by the browser.
• Manual: The portlet will not be automatically loaded and rendered by the browser. The developer must implement code to render the portlet using the JavaScript function reloadComponent.

Note: If you specify other render strategies than Inline, portlet decorations will automatically be rendered for the portlet (i.e. a div-tag with id and class attributes).

The iKnowBase component reload mechanism requires that your pages are served by the iKnowBase page engine, and that the component being refresh was in fact served by a page available at the URL shown in the client browser. That means that these two scenarios will not work:

• You cannot use On load for a page which is manually loaded using ajax. For example, if page “a” does a manual ajax call to load page “b”, On load will not work for any component served by page “b”.