Metric Caching

How Metric Caching Works

• For the Desktop Client, when a Metric value is requested, a query is sent to the CSM database and a result is retrieved. This result is stored (cached) on the local machine of the Desktop Client user who requested the Metric so that it can be used as long as it is considered useful (or fresh). The period of time that this cached Metric value is considered useful varies and is defined in the Metric's definition. Highly dynamic Metric values might be useful for 5 minutes, while very static values might be useful for a month. In any case, when a Metric value exceeds its usefulness (becomes stale), it needs to be re-queried and re-cached.
  Note: The cache value remains in memory until the user closes the Desktop Client, after which it is written to a cache file on disk. After reopening the Desktop Client, the values from the cache file are read from the file and stored in memory for future use. This allows data to be saved when the user is not running CSM.
• For the Browser Client the cache from the hosted server is used, so the information is last-in/first-out. Metrics may often calculate correctly for global information (all Incidents, all Change Requests) but will not calculate correctly for widgets that are calculating for individuals, teams, and roles.

Metric Caching Example

The Metric value is defined to be useful for up to 10 minutes. The first time the Metric value is requested, there is nothing in cache, so a query is sent to the database, and the result is stored on the Desktop Client user's machine. The next time the value is requested, the behavior varies depending on how much time has elapsed:

• If the Metric value is requested 5 minutes later, then the local cached value will be returned because the value is still useful ("fresh enough") that a re-query is not required. That is true all the way up to 9 minutes and 59 seconds.
• However, if the Metric value is requested 11 minutes later, then the local cached value is not fresh enough, so the database will be re-queried.

Frequency

The frequency at which Metric values are cached is determined by three factors:

• Session activity

  Metric values are cached only when a session is active. Users likely closes their sessions every night so Metric values will not be cached during the inactive session. A wallboard, which is always running, might continually cache Metric values for extended periods of time.

• How often the Metric is requested

  Metric values are cached only when requested by a widget or dashboard refresh, or by initiating a query or expression. (Metric values are not automatically gathered.) For example, live trends dashboard might predictably auto-refresh every 30 minutes, an active user dashboard might auto-refresh every 30 minutes but the individual widgets might be manually refreshed more often than that by the user, and an expression might occasionally initiate a request.

• The amount of time the Metric is considered useful (fresh):

  Metric values are re-cached only when their value is no longer considered useful (fresh). This means that a request might not necessarily re-cache a Metric value. The time that a Metric value is considered useful (example: 10 minutes, 24 hours, etc.) is defined in the Metric's definition.

Metric values are cached only when a session is active, only when requested, and only when the value is no longer considered useful (fresh). Consider these factors when viewing Metrics, especially when trending.

Using Cached Values

Desktop Client users can retrieve:

• Current value

  Current Metric value, within context of freshness. In other words, retrieve the current usable (fresh) value sitting in the user's local cache. If value is no longer considered fresh, the value will be re-queried and re-cached (that is, synced with the database).

  (Advanced property) You can also force a re-query each time the value is requested (that is, sync with database); however, syncing affects performance and replaces the local cache value on the user's machine, which could interfere with trending.

• Value from "last cache"

  The Metric value from one cache ago (that is, the value that was cached right before the current value).

• Past value

  A previously cached Metric value that you specify. You can count back (example: From 1 minute ago), specify by first of the month, quarter/year, or select a value from a specific weekday.

  Note: Sometimes, the requested cached Metric value cannot be found (example: Values were not cached during the time you requested). In this case, CSM returns a cached value closest to the requested time (this cannot be the current value). If specifically requested, CSM can instead return a specific defined value or the latest cached value (whatever is currently sitting in cache; might or might not be considered fresh). To help indicate which cached value was returned, users can also select to return the cached value's stored time and whether or not the returned value was the original requested value or an alternate value.

Local Caching Trade-offs

Local caching improves performance because data is delivered faster and fewer requests are made to a database. Local cache values are also stored and reusable, so you can use any value at any time. This is useful for trending.

However, local cached values can:

• Become stale

  Metric values are static for a defined period of time, so values can quickly become outdated.

• Miss a sudden dip or spike

  Metric values are static for a defined period of time, so you might not cache a sudden change in data. For example, you might decide to re-cache a Metric value every 60 minutes. If a drastic event happens at minute 32 but is corrected at minute 35, you will miss it.

• Vary from user to user

  Metric values are cached locally, which means your cached vales and your colleague's cached values might be different, even if they are cached within a few seconds of each other. For example, you might calculate a closure rate of 50 percent because your values were 10 open and 5 closed Incidents. Your colleague might calculate a closure rate of 55 percent because his values were 11 open and 5 closed Incidents.