In ignition 8.1 I have a chart component in a repeater, right now our historian is queried on every chart and then the data is processed to fit the chart. This means that its being done at the client level rather than at the gateway level and retrieved. It has gotten slow as we hit 80+ charts, and I’m wondering what the most efficient method of storing and retrieving these datasets would be. The tag value is either stored on change or every hour whichever is first and is a string value. I could have anywhere from 24 rows to 20,000 rows per dataset. Should I create a gateway script and try caching one big dataset for all charts or are dataset tags an option? I’d like to make the data available for all clients to grab.
Vision? Perspective?
I generally recommend caching in project library script top-level variables. If you use my toolkit's system.util.globalVarMap, you can trigger expression binding updates when the content is changed.
Perspective, sorry forgot to include that! Do you have any examples of a situation like this?
Share more about how your queries are run for more specifics, but the general outline will look like this in a project library script:
# Cache for hourly historian queries
# script name hourlyHistories
cache = system.util.globalVarMap("hourlyHistoryCache")
histQueries = [
dict(key='someName', historyPaths=[...], ...queryargs...),
dict(key='anotherName', historyPaths=[...], ...queryargs...),
...
dict(key='finalName', historyPaths=[...], ...queryargs...)
]
# Call this from a gateway startup event, and from a hourly scheduled event.
def populateCache():
for config in histQueries:
cache[config['key']] = system.tag.queryTagHistory(...)
cache.refresh()
# use Expression Binding like so to retrieve datasets in UI:
# globalVarMap("hourlyHistoryCache")['someName']
For updates on change, pick out and run just the affected queries, then fire cache.refresh().
Any idea if this would be resource intensive? I need to ensure the solution is scalable
It's going to trade off memory for CPU/wall clock time, as any cache does.
It's going to be about an efficient a cache as you can readily maintain in Ignition. Datasets are not particularly efficient constructs, but they're also not particularly inefficient. It's going to be better than storing via dataset tags, which require a lot of extra baggage to serialize values for persistence, potentially synchronize with clients/designers, etc.
For Perspective, all of the expression bindings in your UI will share single copies of the datasets. (Mark your custom props private, for even better behavior.) No other solution would be as efficient.
Perspective does all of this work in the gateway, not in the browser, so this would be especially effective.