Configuring cache settings for the mid tier


You can configure cache settings for the mid tier on the Cache Settings page of the Mid Tier Configuration Tool.

Mid-Tier-Config-Tool.png

Related topics

Mid Tier Configuration Tool - Cache Settings page

The settings are as follows:

Setting

Description

Sync in cluster

Indicates whether you want the cache to be synced automatically on a group of mid tiers. This option allows you to see the changes from Sync Cache from any Mid Tier in the group without clearing browser cache.  

If the check box is:

  • Selected—The cache will be synced periodically and simultaneously across all mid tiers in a group. It does not require the mid tiers to be in a clustered deployment. All the mid tiers run the timed Sync Cache at the same time if the following conditions are true:
    • The Mid Tiers in the group should have the same interval definition specified from the Definition Change Check Interval field of the AR Server Settings > Edit AR Server Settings page.
    • The mid tiers should be running on computers with the same system clock time.

      The Mid Tiers in a group do not communicate with each other internally. All Mid Tiers that have same system clock time and Definition Change Check Interval value are defined as a group of mid tiers.

  • Cleared (default)—The cache will be synced automatically at the interval that you specify on each mid tier in the Definition Change Check Interval field of the AR Server Settings > Edit AR Server Settings page.

To enable faster previewing of changes to forms and applications in a browser, and to enable users to see updated information more quickly, you can use the Sync Cache option for the available servers. Selecting this option for a server clears only those objects that have changed on that server since the last time the cache was cleared.

For more information about this option, see Knowledge Base article ID 000226959. (You must be logged in to the BMC Support site to access this article.)

Resource Check Interval (Seconds)

The time limit (in seconds) for which resources (such as images, .css files, and JavaScript files) can be used. The default value is 86400 seconds. If a user closes a form and opens it again within the specified expiry time, the image is cached and is not downloaded again. This helps increase the performance of Mid Tier.

Enable Cache Persistence

Specifies whether forms cached in memory are written to files for faster retrieval. If the check box is:

  • Selected—Forms cached in memory are written to files. This option enables faster retrieval of forms when the server is restarted.
  • Cleared—Forms cached in memory are not written to files.

AR System forms can be stored on disk only after Enable Cache Persistence is selected. AR System forms loaded before the Enable Cache Persistence is selected are not saved to disk.

When a user opens a AR System on a form for the first time, Mid Tier must download the form and its workflow objects. It must then construct a Java object from these items. This object is used to generate the Dynamic HTML needed to display the form in a browser. The initial construction of this Java object is time-consuming, but after it is built, Mid Tier caches it in memory and accesses it for all users who open the same form from that point on. Forms currently cached in memory can be serialized (written to) to one or more files, which enables the forms to be retrieved faster.

Mid Tier can serialize the constructed Java objects that represent AR System forms present in memory and write them to a file when the form is loaded. Mid Tier detects the file, reads it, and reconstructs the Java objects serialized in it. This prevents the system from having to repeat the time-consuming construction process. 

If the application server hosting Mid Tier shuts down unexpectedly, Mid Tier reloads all forms specified in the prefetch configuration from the AR System server when the application server is restarted.

Backup Directory

Full path of the directory where good cache backup exists. For more information, see Backing-up-the-mid-tier-cache.

Flush Cache

Removes all items from the caches that BMC Mid Tier maintains. The next time the Mid Tier needs those objects, the most up-to-date versions are retrieved from the AR System server.

Flush Cache-All pods 

Clears local cache from all Mid Tiers in the cluster. 

Sync Cache

For the selected servers, clears the cache only for the objects that have been changed.

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)

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

  • Group data
  • Role data
  • Image objects
  • Currency codes

Whenever AR System server successfully applies a deployment package, the Mid Tier receives a notification and can sync the cache automatically.

With multi-tenancy:

  • Additional cache categories optimize the cache footprint by sharing common metadata across the AR System servers. This helps improve scalability and performance of mid tier instance while using Mid Tier in multi-tenant mode. If you are running the mid tier in multi-tenant mode, use the Sync Cache option over the Flush Cache option to avoid removal of complete cache contents rather than just refreshing changed objects in the cache.
  • Always use Sync Cache option to get any of your metadata changes reflected in mid tier. There should be no reason to use the Flush Cache option unless you see cache corruption (such as EOFException) in the Mid Tier logs due to an unclean shutdown or some other system issue. The Flush Cache option hinders the mid tier performance as compared to using Sync Cache, and the performance-related issues multiply when running the Mid Tier in multi-tenant mode.

Preload (button in the Action column)

 Triggers the preload process for the specified AR System server.

Preload (column)

Describes the preload status. The values are as follows:

  • Disabled—If preload is turned OFF from AR Server Settings page for the specified server.
  • Not Running—If preload is turned ON from AR Server Settings page while the Mid Tier is running.
  • Running (displays a progress bar)—If preload is in progress because of Mid Tier startup, or because you started preload by clicking the Preload button from the Cache Settings page.
  • Completed—If preload has completed successfully.
  • Aborted—If preload was aborted because of some error. For example, preload was aborted because the AR System server is not reachable, or has restarted, or has timed out. The Mid Tier logs contain more about the failure.

For more information, see Configuring-AR-System-servers-that-the-mid-tier-uses.

Sync Status

Describes the sync status. The values are as follows:

  • Disabled—If the Perform Check checkbox  is unchecked from the Edit AR Server page of the AR Server Settings page.
  • Not Started—The default state.
  • Starting—The intermittent state when Sync Cache button is clicked.
  • Running—If sync operation is in progress.
  • Completed - <timestamp>—If sync operation has completed successfully, and has deleted some metadata from the cache because of the changes detected on AR System server.
  • Nothing To Sync - <timestamp>—If sync operation has completed successfully, but there are no changes to the metadata changes on the AR System server.
  • Failed—If some errors occurred during the sync operation. The Mid Tier logs contain details about the failure.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*