Warning: A non-numeric value encountered in /home/heimdal9/public_html/wp-content/themes/Divi/functions.php on line 5763

The analytics tab provides an overview of the traffic behavior observed by the Heimdall Driver and logged to the Heimdall Central Manager. With it, you can drill down to particular times (or analyze all available data) and drill into particular VDB log files and/or data sources.

The columns of the report are as follows:

Rank: The ranking of a pattern as currently sorted
One-Click Cache: If the VDB was selected, this will provide a button that selects a policy to be cached, converts it into a regular expression, and adds it as a rule into the policy list. A commit will be needed to make this rule effective.
Query: The query pattern the row is associated with. This will be a summarized format, with variables replaced with a ?, much like in a prepared statement format.
Server Time: The percentage of time processing this query pattern vs. all patterns.
Duplicate Query & Response: What percent of the queries of this pattern that duplicate other executions. The higher this value, the more likely the query pattern will be a good candidate to cache.
Cache Safety Rating: A ranking from 0-100 on the safety of caching this query. Currently the estimate is not reflecting reality well, and will be updated in releases post 1.0 Beta 4.
Cache Index: This provides a ranking of the safeness of caching a query from 0-100. The higher the value, the better the choice to cache.
Cache Time: This is a recommended time to cache, in order to avoid stale cache. If using Trigger based cache invalidation, this can largely be ignored.
Cache Hit %: The overall cache hit rate for the pattern in the data analyzed. With async execute operations, if an operation was done in an async manner, this field will also be used, as it represents a “fully optimized” response.
Count: The total number of queries that matches the pattern for the row.
Query Response Time: The value in microseconds for the average response time, including cache hits and misses. To analyze the before and after impact of caching, this time should be recorded without caching active (or a time period during which caching was inactive analyzed), and then the time period after caching was activated.
Result Retrieval time: The time taken to retrieve a result set from the server, when not a cache hit. This time will also include the result set processing time, which in general should be a small, but additional time vs. the time reported over query response time, IF no caching is involved, and reflects application think time while processing the results, and any additional overhead to pull larger result sets from the server.
Total KBs: The total amount of data in KB retrieved from the server for this query pattern.