One of the most common issues when implementing Heimdall is the lack of cache hits. There are many different reasons why with a default cache policy as generated by the configuration Wizard, cache hits will not be observed. Each of these will be detailed below and how to diagnose them.
First off, when debugging caching, the following steps should be followed:
- In the vdb tab, enable the "verbose debugging" option
- Next, pass traffic you expect to be cached
- Finally, check in the logs tab (or the log files on disk), and search for "nocache reason"
The debug logs will provide the reason why caching is not occurring for any query that is matching a cache rule in most cases.
Queries in Transactions
As queries in a transaction may have different side-effects than those that are not, so, by default, the wizard creates a rule that does not trigger caching or cache retrieval while in a transaction.
This cause will NOT have a nocache reason (it simply won't be shown), as it is triggered in the rule match process itself.
As queries in a transaction may have different side-effects than those that are not, by default, the wizard creates a rule that does not trigger caching or cache retrieval while in a transaction.
Frequently Written Tables
By default, if a table is written to more than one out of every twenty queries, then the table will be considered non-cachable. This can be tuned in the cache rule parameter of "dmlThreshold". A value of 5 (for 5% dml) is the default.
System Table Detected
Certain table names such as pg_* will be flagged as being system tables, and which may be changed behind the scenes by default. In these cases, the default behavior is to disable caching. This can be overridden with the cache parameter of "cachesystem".
No Tables Detected
As invalidation is tracked at the table level, if no table is detect in a query, the default behavior is to disable caching. This includes for queries such as "Select 1". This can be overridden by tagging the query with a table of "none". This is a special value, in that it explicitly removes this tracking behavior.
Table Was Written To
As a DML is detected, the table will enter an invalidation window, which is a period of two seconds during which neither cache hits nor cache stores will occur. This includes for the entire duration of a transaction the DML is detected within, until a commit or rollback. Once the DML is completed, the invalidation window will no longer be in effect, however, for remote nodes, this window will occur for at least the full two second period. This is to reduce the number of messages traveling between nodes. Updates to refresh the invalidation window will occur every second until no dml is pending against the table. Updates can be made that don't trigger an invalidation window by using the parameter "invalidate" with a value of false.
Temporary Table Detected
When a temporary table is detected in a query, this will suppress caching as well.
Non-Deterministic Function Call Detected
With SQL Server, function calls are parsed, and non-deterministic functions are detected. When present in the query, this will trigger cache suppression.