The Perspective documentation eludes to some magical properties of a "polling engine" when the "Cache & Share" is enabled:
When this setting is enabled, the binding will utilize a polling engine that is shared across all running Perspective sessions. The polling engine will poll once, cache the value, and deliver the results to all registered consumers. The cache persists for a period of time that matches the configured poll rate. If polling is off, the default cache duration is 250 milliseconds. This optimization is helpful for consolidating multiple identical polling tasks, particularly when you have many Perspective sessions running at once. Disabling this option will bypass the cache.
In practice, what does this mean for the volume of queries (and the resultant rows scanned/rows returned) between the Gateway <-> Timeseries database?
It seems to me that system.tag.queryTagHistory would go directly to the database each time if the provided time range is different in a polling scenario, where first/last timestamps would always inch forward.
Using the tag history bindings with "Cache & Share" would then seem to only fetch the newest data between the last polling interval?
This seems critically important, especially if there are many historical queries that land in the date range for timeseries tables that are actively filling with data (e.g. last 1 hours of data for an active set of tags in a system). Even with Cache & Share, if the timeseries databases are under constant pressure for insertions and selects, is there a point where people have set up read-only replicas of timeseries databases to direct tag history queries against?
The impact seems obvious, but I'm curious about folks experiences regarding this polling engine. The role it plays in Perspective projects is immense, and it seems helpful to re-create/expose the polling engine for other types of gateway activity that may rely on these types of polling tasks (e.g. gateway scripts that need to poll various historical traces). Of course, memory usage could easily balloon and tuning the various parameters of a more general purpose polling engine to maintain performance for most scenarios is not a cakewalk.
I went into some detail on how the 'Cache & Share' mechanism works here:
The main benefit for the historian is when you're dealing with the exact same query being issued by multiple sessions at once.
Without cache and share, that's multiple hits to the database to return the exact same data.
With cache and share, that's optimized away, trading off some memory for the DB hit.
It is not a general purpose value cache bucket (like Vision has...), something Perspective lacks. That is, cache & share does nothing for a power chart that's querying "the last five minutes", and then a second later "the last five minutes" again, with 4:59 of overlap between the two queries.
Does the polling engine in the Perspective Tag History binding attempt to only fetch the next interval of data for an existing "polled' timeseries if the query cache already holds some number of raw datapoints already from the prior query window?
For example, if I have a polling tag history binding, fetching the last hour of data every minute, will that polling engine only fetch the next minute when the binding is still loaded in at least one session?
This stuff is rather opaque, so it's hard to know when you're using the most out of it, especially for the Perspective Tag History bindings.