This documentation supports the 19.08 version of Remedy and applies only to the on-premises deployment model.

To view an earlier version, select the version from the Product version menu.


Configuring mid tier issued browser cache directives

A standard web technique to improve the performance of a browser is to tell the browser to cache contents that are infrequently changed so that the browser uses the cached contents on subsequent requests instead of requesting the contents from the web application. This is called browser cache directives, and it is optionally issued by a web application with each response. To configure the browser to observe the cache directives, see Browser hardware requirements and settings.

The mid tier web application issues cache directives for all of the Remedy AR System web platform resources and almost all of the UI components. (For security reasons, the data portion coming from the mid tier is explicitly directed to never be cached by the browser). The duration of the cache directives is controlled by the following properties located in midTierInstallationDirectory/WEB-INF/classes/config.properties:

  • arsystem.resource_expiry_interval — The duration (in seconds) the browser must cache mid tier platform resources, such as images, icons, CSS, ClientCore.js, and other platform resource
  • arsystem.formhtmljs_expiry_interval — The duration (in seconds) the browser must cache the UI and active links (transformed into JS) associated to forms

Regarding the arsystem.formhtmljs_expiry_interval properties, the mid tier generates a unique URL pattern (per user group) for access. This ensures that there is no security violation with the cached UI and active links even if there are two users with different group access privileges using the same browser on the same computer.

Note

Any changes to these properties require a restart of Tomcat or the web server hosting the mid tier for the new values to take effect.

Strategy for configuring the browser cache directive

In a production environment where the Remedy AR System definitions are not changed, set the properties to at least 1 day (86400 seconds). Though you can manage each separately, setting them to the same value eases management when altering Remedy AR System web platform resources or definitions.

These properties define how often the browser should check with the Mid Tier for updates. So, in a typical deployment environment where the Remedy AR System applications and platform are no longer being modified, you might set the parameters to a week or longer.

The browser’s behavior in relation to the Mid Tier-issued cache directive is as follows:

  1. The browser requests for a resource from the mid tier.
  2. The mid tier delivers the resource with the browser cache directive (for the duration as configured).
  3. After the cache directive has expired for the resource, on a subsequent browser request (or a browser refresh) for the same resource, the browser sends a request to the mid tier with the original cache directive.
  4. On receipt of the request, the mid tier checks to see if the resource has changed since the cache directive was issued.
    1. If the resource has not changed, the mid tier returns an HTTP 304 response header (with no data payload) instructing the browser to reuse and update the cache directive of the resource.
    2. If the resource has changed, the mid tier returns the new content with a new cache directive.

When content is unchanged, the response has zero data payload. However, on networks with bandwidth saturation or long latency, many such requests can result in poor browser performance because the request/response cycle takes time. Setting the browser cache directives to a longer value means fewer browser checks with the mid tier for changed content, which results in faster use case times. Set the cache directive interval correctly so that the browser does not have stale contents.

Note

In production, suppose these properties are set to 1 week, and a change in a definition occurs. If the change is for a non-user-facing form, then the change takes effect as soon as the form definition is saved to the AR System server. If the change is for a user-facing form, after the mid tier has synchronized with the AR System server, the users who have accessed the changed form within the last week (less than 7 days) must refresh their browsers or clean out the browser cache to see the change.

Most companies roll out the changes over a weekend. If both properties are set at 1 day, then on a Monday when users access the mid tier, they will receive the new changes. However, deployments that are 24 hours a day, 7 days a week must adopt a different strategy of browser caching.

Was this page helpful? Yes No Submitting... Thank you

Comments