About Mid Tier caching

The first time a form, view, or form and view combination is requested via BMC Remedy Mid Tier, performance can be impacted by the intensive processing necessary to obtain the form, field, active link, and associated information from BMC Remedy AR System server. This can be time consuming when there are large forms with many fields and many associated active links. It is also important that memory is not consumed for forms that are not accessed.

Also refer to the mid tier caching recommendations.

CACHE: SetupServlet:init: Version change is detected due.
Older version = 0 New version = 5 Cache has to be flushed and rebuild

To minimize the usability impact of this performance hit, the Mid Tier Configuration Tool includes the following configuration options:

• Flush cache — Removes all items from the mid tier cache. When the objects are requested, the most up-to-date versions are retrieved from the BMC Remedy AR System server. For details about the Flush Cache feature, see Flush Cache.

• Sync cache — Clears only objects that have changed on the server after the last cache clear event. In this case the mid-tier contacts BMC Remedy AR System server and compares the last-changed-timestamp on elements and synchronizes any changes. For details about this feature, see Using the sync cache option.

  Note

  -- The Sync cache option is not available for 7.1.0 and prior releases.

  -- When you restart BMC Remedy Mid-Tier (or Tomcat), it starts building views and performing sync cache operations to ensure that the cache contents are up-to-date. Loading those views in the cache takes time if there are a lot of AR System server views in the viewstats.dat statistics file, which subsequently delays the sync cache operation. During this period, if mid tier gets any request, it sends the older version of the requested data.
  
  As an administrator, you can check the sync status on the Cache Settings page to verify whether the sync was completed successfully.

• Definition Change Check Interval — This mid tier cache setting is configured to set an interval (in seconds) at which information in the cache is updated. The default value is 86400 seconds. For details about the Definition Change Check Interval setting, see AR Server Settings.

Mid tier caching recommendations

Whom does this information benefit?

If you are using the caching recommendations developed on the prior design of mid tier's caching infrastructure you may be restricted in realizing the benefits of the new design. Use the information provided here if you are a user of:

• version 7.5.00 patch 004 of AR System Mid-Tier
• version 7.5.00 of AR Server any patch level or higher
• version 7.1.0 of AR System  - except new Sync Cache feature

Recommended caching setup and procedures

• Disable Mid-Tier Prefetch — Prefetch has always been a brute force approach to loading forms into memory based on a somewhat arbitrary list of forms configured in the prefetchConfig.xml file by the system administrator. Forms and other cache objects end up in memory, but are not actually ever used by end users wasting valuable memory space. To disable Prefetch, log on to the Mid-Tier Configuration tool, on the Cache Settings page, remove the contents of the prefetchConfig.xml file so only these elements remain and save changes:

<?xml version="1.0" encoding="UTF-8"?>
<midtier-prefetch-config&nbsp; xmlns="http://www.bmc.com/remedy/midtier/midtier">
</midtier-prefetch-config>

• On the AR Server Settings page, ensure that the Perform check check box is selected. The Perform check check box activates the feature called Sync Cache that eliminates the need for administrators to flush the entire Mid-Tier cache after a form, active link, menu, etc. definition change on the AR System server. Mid-Tier now automatically synchronizes its cache for just the changed objects. It performs this check at the interval selected in the Definition Change Check Interval field. Or, an administrator can press the new Sync Cache button on the Cache Settings page to have the changes synchronized immediately. The Sync Cache operation, whether done automatically via Perform check interval or by pressing the Sync Cache button for the AR System server, synchronizes any of the following objects whose last changed timestamp is newer on the AR System server than in the current mid tier cache: Forms, Active Links, Containers (such as Guides, Applications, Web services, etc.), and Menus (Character menus). Sync Cache completely removes and rebuilds the following cache items since the performance hit is minimal: Group data, Role data, and Image objects.

• On the AR Server Settings page in the Mid Tier Configuration tool, enable the new feature, Preload, by selecting the check box. Preload will, on a restart of mid tier, load all Active Links and Menus to the disk cache and any form which is user facing, that is, any form which has an Active Link associated with it.

• Select the Enable Cache Persistence check box.
• Save changes to the AR Server Settings.
• Shutdown the JSP engine. Remove the contents of mid tier's /cache and /cachetemp directories and start the JSP engine.

• Allow Preload to complete processing.

• Allow end users access to the system. BMC recommends allowing at least 1-2 days of normal end user usage of the system. This type of activity is desired because mid tier updates a statistics file of what forms and views the users are accessing. This statistics file, viewstats.dat, tracks which forms/view combinations are being accessed, which group combinations are accessing, and how many hits each has.

  Note

  The viewstats.dat statistics file is not related to the cache (ehcache) statistics (see About the cache table). The viewstats.dat file is based on user activity and is not dependent on any configuration.

• After 1-2 days of usage, disable Preload using the Mid Tier Configuration tool, by deselecting the check box on the AR Server Settings page.
• Stop the JSP engine.
• Start the JSP engine. With Prefetch and Preload disabled, the mid tier, upon startup, use its statistics file to quickly load up into memory from the disk cache, only forms which users have been accessing. This allows for the most efficient use of mid tier's in memory cache and the best form access performance for end users.