Best practices for configuring mid tier cache

To maximize the performance and usability of Mid Tier, we recommend the following configuration best practices.

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 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

Caching setup steps

  1. Disable Prefetch by completing the following steps:

    1. Log on to the Mid-Tier Configuration tool.

    2. 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>

    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.

  2. On the AR Server Settings page in the Mid Tier Configuration tool, 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.
  3. On the AR Server Settings page, select the Pre-Load 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.
  4. On the Cache Settings page, select the Enable Cache Persistence check box.
  5. Save the changes.
  6. Shut down the JSP engine. Remove the contents of mid tier's /cache and /cachetemp directories and start the JSP engine.
  7. Allow Preload to complete processing.

  8. 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.

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

  9. After one to two days of usage, disable Preload by clearing the check box on the AR Server Settings page.
  10. Stop the JSP engine.
  11. 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.

 Activating Perform Check

Sync Cache eliminates the need for administrators to flush the entire Mid Tier cache after a form, active link, menu, or other definition change on AR System server. When this feature is activated, the Mid Tier cache is automatically synchronized with the changed objects. The check is performed at the interval selected in the Definition Change Check Interval field.

  1. In Mid Tier Configuration Tool, click Cache Settings.

  2. On the Cache Settings page, make sure that the Sync in cluster check box is selected.
     This activates Sync Cache.
    Sync-in-cluster.png
    An administrator can press the new Sync Cache button to have the changes synchronized immediately.

    The Sync Cache operation synchronizes any of the following objects, if the changed timestamp on AR System server is more recent than the cached item in the Mid Tier cache:

    • Forms
    • Active links
    • Containers (guides, applications, web services)
    • Menus (character menus)

Because the performance hit is minimal, Sync Cache completely removes and rebuilds the following cache items:

  • Group data
  • Role data
  • Image objects

Activating Pre-Load

When the Pre-Load option is activated, the following items are loaded when the server is started (or restarted):

  • Active links and menus in the AR System server, and all user facing forms (any form with an associated active link)
  • All usage history data

The preload process starts after a 10-second delay.

  1.  Enabling Cache Persistence Open the Mid Tier Configuration Tool and click AR Server Settings.
  2. Select the server to edit, and click Edit (If you are adding a server, click Add Server).
    config tool_ar server.png
  3. Select the Pre-Load check box.
    Config tool_server settings.png
  4. Click Save.
    You can enable faster retrieval of forms when the server is restarted by activating the Enable Cache Persistence option.
  5. In the Mid Tier Configuration Tool, click Cache Settings.
  6. Select the Enable Cache Persistence check box.
    Config tool_enable cache.png
  7. Click Save Changes.

 Clearing the cache and restarting the server

Use the followings steps to clear the cache and restart the server after implementing the setting changes.

  1. Shutdown the JSP engine.
  2. Remove the contents of the following mid tier directories:
    • cache
    • cachetemp
  3. Start the JSP engine.
  4. Allow Pre-Load to complete processing.
  5. Allow end users access to the system.
     Before moving to the next step, it is recommend to allow one to two days of normal system usage. Patch 004 provides functionality to update the statistics file (viewstats.dat) with the following information about forms and views access requests.
  6. After 1-2 days of usage, disable Pre-Load in mid-tier configuration tool by clearing the check box next to the AR System server name on the AR Server Settings page.
  7. Stop the JSP engine.
  8. Start the JSP engine.
     With Prefetch and Pre-Load disabled mid-tier will on startup use it's statistics file to quickly load up into memory from the disk cache only forms which users have really been accessing. This will allow for the most efficient use of mid-tier's in memory cache and the best form access performance for end users.

Using the Mid Tier with third-party load balancers

Remember the following tips when load balancing:

  • To have multiple instances of a Mid Tier web application work correctly in a load-balanced environment, configure the load balancer so that the mid-tier instance of the user's first HTTP servlet request is routed to the server that maintains affinity (stickiness)—the connection for the life of a session. "Session affinity" in this context refers to how requests from the same client (in a cluster of servers) are always routed back to the same server, eliminating the need to replicate session data such as HttpSession.
  • On the JSP/Servlet engine, enable cookie-based session tracking (the default), as opposed to tracking by URL re-writing, which the mid tier does not support.
  • The mid tier does not support failover. Failover to a backup mid tier invalidates the user's HTTP session on the failed Mid Tier. (Failover is not transparent to the user. They would see a 9201 "Session timeout or invalid" error in their browsers and would need to log in again.)

While AR System supports the use of load balancers, BMC does not test or recommend a specific third-party load balancer. BMC supports AR System within the environment, but not the configuration or debugging of a load balancer itself beyond generic interaction expectations of AR System with any load balancer.