Caching configuration

#1

I’ve a dashboard that runs some very slow metrics. I’m trying to setup caching to not have to run the metrics every time the user hit the dashboard.

I’ve end up with some examples, like defining a file SomeType-MetricsCacheConfig.json under TenantConfig with following content:

{
  "id": "SomeType-MetricsCacheConfig",
  "name": "Cached metrics for loading the dashboard page",
  "jsonValue": {
    "enabled": true,
    "srcType": {
      "moduleName": "somepackage",
      "typeName": "SomeType"
    },
    "metricNames": [
      "Metric1",
      "Metric2"
    ],
    "interval": "DAY"
  }
}

Is this enough? are my metrics Metric1 and Metric2 cached? because I saw that we can also have:

{
  "id" : "Metric1_SomeType",
  "name" : "Metric1",
  "srcType" : "SomeType",
  "expression" : "some magical expression",
  "description": "this metric does something magical",
  "cache":  {
      "intervals": ["MONTH"],
      "monthsInPast": 12
   }
}

I’ve also find examples for using ‘caching’ in a UI datasource:

ui module Dashboard {
    dataSource SomeTypeMetricMain {
        "collection": false,
        "record": true,
        "cache": true,
        "c3type": "SomeType",
        "c3function": "evalMetric",
        "responseSelector": "data",
        "responseTransform": {
            "firstItem": true
        },
        "c3arguments": {
            "spec": {
                "expression": "latestValue(Metric1)",
                "start": "{{ standardMoment(createDynamicDate(['start', 'hour'], 'before', '1', 'year')) }}",
                "end": "{{ standardMoment(createDynamicDate(['start', 'hour'])) }}",
                "interval": "MONTH"
            }
        }
    }
}

What’s the difference between these ways of enabling caching for a metric? are there other ways to do it?
Once the caching is in place, how can I check that the cache is properly invalidated at the interval I specified? How do I invalidate all cached data?

Is there a documentation for properly configuring caching?

0 Likes

#2

cache field in DataSource in UI Client is unrelated to metric cache.

0 Likes

#3

then what is it (DataSource cache) used for?

0 Likes

#4

It is for UI Client to cache the data for exact same request.

0 Likes

#5

can I use it with metric side cache, there will be no interference? how/when the UI one is invalidate?

0 Likes

#6

@bachr - you are right about this approach to cache metrics. The other approaches wont work

{
  "id" : "Metric1_SomeType",
  "name" : "Metric1",
  "srcType" : "SomeType",
  "expression" : "some magical expression",
  "description": "this metric does something magical",
  "cache":  {
      "intervals": ["MONTH"],
      "monthsInPast": 12
   }
}

The metric will be cached on first evaluation and then will be served from the cache until the cache is invalidated.

Note: that action decl based metrics don’t currently get invalidated.

2 Likes

#7

thanks Rohit.

Two questions:

  1. What is the recommendation to actually create these if we dont want the customer to have to sit through the first time load?

  2. What is the invalidation process? I dont see it defined above?

0 Likes

#8

Answers:

  1. At this point the best approach is to have a cron job kicked off to read the metrics after every data load (could be nightly, weekly, …)

  2. The invalidations are automatic and the same as applied to trigger any analytics. This includes handling changes in fields referenced by tsDecl metrics or any TimeseriesDataPoint or TimedDataPoint changes

0 Likes

#9
  1. Is it possible to force metric (normalized data) cache invalidation by something more high-level than searching for a related data point and upserting it (for example)?
0 Likes