Spectre Caching

The DiveLine server caches all requests made through the Spectre engine. This on-disk cache stores the queries as well as the results of all dives, including dimcounts, QuickView populations, and Dive windows. ProDiver markers against cBases are translated into Spectre Dives, so both the queries and the results are cached.

The DiveLine server cache is stored in the dl-dataroot\cache\spectre directory, or you can configure an alternative location in Workbench. (NOTE: Virus scanning should be turned off for this directory.)

Shared Cache

If a dataroot is shared between different DiveLine servers, so is the cache. When a DiveLine client requests data from the Spectre engine, the engine checks its cache to see if the entry is available.

  • If the entry is available, Spectre ensures that it is "fresh" (for example, that cBases, cPlans, Lookup files, Access Control, and Aliases have not changed).
  • If the entry is not available, Spectre runs the request and saves the result in the cache for future requests.

Note that access control is a part of the freshness information for a request. If two different users make the same request and they have the same access to that data, then they use the same cache entry. If they have different access, or they dive in a different order, they use different cache entries.

About the Cache Files

The cache files are stored on the server based on a hash of their contents, allowing rapid retrieval. If the system sees significant ad hoc diving, the number of hash files can grow significantly. You can periodically delete the cache directory, or manage the cache files using the command line tool spectre cache. With this tool, you can examine the size and age of the files, selectively delete them, or even refresh them. Cache refresh is often used after rebuilding cBases, in order to update the results for recently run queries. This ensures that the first look by an end-user does not include time to cache the query.

Cache During Software Upgrades

Starting with version 7.0(50), when updating a DiveLine installation using the installer, the installer restarts the DiveLine service before removing stale Spectre cache files—this minimizes downtime. Users can use the service right away, there is no risk of bad cache data, and the cached information on requests is preserved, but slightly delayed, as the installer continues to run and copies the requests and metadata into the new empty cache. Note also that when the DiveLine server is upgraded, all files in the cache with a file extension of data are deleted.

Cache Refresh Options

To improve the speed of displays, you can "seed" the cache by making requests in advance. When the data is actually requested, Spectre simply uses the cache. If you need to seed the cache for multiple users with different access to the data, you need to make requests on behalf of all of those users. This can be automated using DIAL to run selected queries (for example, for users or for DivePort pages) or by using spectre cache to refresh all or selective recent cache entries. Both DIAL queries and Spectre cache commands can be scheduled using the Execute process node in Production.

The easiest way to keep your cache fresh is to use the Production Spectre Cache Refresh node as a final step in your cBase maintenance process. This node can refresh any and all Spectre dives currently in use based on the contents of the cache area. The refresh applies to all projects on the server.

Cache During Development

To ensure that your applications perform well, you need to develop and test them in a realistic way prior to deployment in production. It is best practice to disable the cache during development and testing so that you see the worst case timing. An exception to this practice is to enable caching when stress testing so that you can anticipate response times under maximum usage.

Caching should always be enabled in production to optimize performance and response times.

Caching is on by default. To turn it off, change the permissions on the cache directory so that the DiveLine server does not have write access.

Cache During Frequent Builds with Heavy Usage

Users do not always logoff, but often go idle. If you frequently rebuild your cBases, disk space may be consumed because you have several generations of cBases open at once, due to idle users. This is because the cBases are kept open in case the user dives again—but they do not. Even though the file gets deleted when rebuilt, the earlier versions persist until all file handles to them are closed. That means one of the following occurs:

  • The user performs another dive on that cBase (Spectre notices it has changed and reloads it)
  • The user closes the cBase
  • The user terminates their session
  • The DiveLine service is restarted

Enabling the idle session timeout for DiveLine clients helps if set comparable to the rebuild-time (for example, 60 minutes, 90 minutes).

As of version 7.0(54), DiveLine/Spectre periodically ejects stale entries from the in-memory cBase cache so idle clients do not keep old cBases open when those cBases are rebuilt.

See also:

Mentioned in: