Hello everyone,
I’m looking for some technical advice regarding the management of several Query Tags configured within a UDT.
Currently, these tags operate with a rather long Fixed Rate (5-10 minutes) but I run into a critical issue every time the server is restarted. In these instances, the data is only updated once the first scan interval is reached, forcing me to wait a long time before seeing the actual values in the system.
I was wondering if there is a native way to force these queries to update at Gateway boot, or if it’s unavoidable to implement a custom solution to bypass the wait for the first refresh cycle.
Thank you
Query tags should be minimized where possible, in my opinion. That aside, I would assume they would run immediately on boot up. I cannot understand why it would wait for the end of a polling cycle.
If they really do not poll on boot, you could turn them into dataset memory tags and use a script to populate the tags as needed.
You could also create a custom tag group and use system.tag.requestGroupExecution() to force polling as necessary.
Wondering if they're running on boot, but the DB connection isn't yet alive...
Yeah, I thought about that too, but you would think that the boot up sequence would be such that DB connections are brought up before tags and other possibly DB dependent items.
First of all, thank you for your support.
I hadn't considered it, but the issue might indeed be related to the database connection timing. I plan to run some tests on a staging server to verify this behavior.
In the meantime, I’m thinking of implementing a workaround: checking if at least 30 seconds have passed since reboot (using the [System]Gateway/UptimeSeconds tag) and then forcing a refresh via system.tag.requestGroupExecution().
I would also like to dive deeper into why I should avoid using Query Tags. In my current setup, I have about 300 UDT instances, each representing a single production machine. Each instance has a Query Tag that retrieves KPI data every 5 to 10 minutes. This UDT-based structure is very easy to maintain and scale.
What would be a better or more "best-practice" alternative for this kind of requirement?
Thank you
Query tags have their uses, but if you're not careful you can slam the DB with them. I.E. accidently changing the tag polling rate, which could also slow down the execution of other tags.
Are the KPI numbers only for the UI? If so, it may be better to make it a named query with a binding and parameters which is easier to control the execution timing and caching.
If you really need it in the UDT, maybe look at doing a single query tag outside the UDT for all machine KPIs then use a lookup() expression tag in the UDTs. This would touch the DB once instead of 300 times every polling cycle.
Thanks for the input.
I’ll do some testing to optimize this task, mainly evaluating the use of a single batch query versus using lookups.