Hello,
I’ve got a table component configured at a poll rate of 300 seconds. It’s bound to a named query. It’s running the query about 192 times per minute. There’s only ever 2-3 sessions running at one time. I’m at a loss as to why it’s not executing the query at the designated poll rate.
Thank you for your help.
What part of it is configured? Sounds to me like perhaps the named query is in the wrong place, like a property change or a extension function that gets called per cell. Please show and explain how it’s actually setup.
I’ve got the named query disabled right now, as to reduce load on the server. But below is the configuration.
That is weird. I’m spitballing but maybe as you’re looking at the configuration it to figure out what’s going on it’s polling again.
Do you still see the same number of executions if you close your designer? Are you still seeing the same number of calls with designer closed for more than 60 seconds?
How many sessions does your gateway say are active on the gateway config page? It’s possible there are more sessions being opened than you realize. I’ve seen situations where people get excited with the idea that they can see their SCADA from their phone and the client count grows from there.
If you’re getting a massive number of client instances running you can still scale it well by simply polling the data in a script on the gateway side and binding your table to that data. That way you’re forcing it to only poll once for any number of clients.
EDIT:
You could probably use a database tag for this. Make sure your query is really fast if you’re doing that and you probably want to set up a custom tag group to specify the desired execution rate for the database tag.
You have tags configured in your expressions for your parameters. Anytime one of those changes it will trigger the binding. I’m not sure that adds up to 192 / min, but it could possibly explain having a higher rate than expected.
If you set the prameters to static values does it trigger at the rate expected?
I don’t know how I didn’t notice that but I’m fairly certain that’s the solution.
Try now(300000).
The way it is it's going to re-evaluate at the default scan class rate.
Look for other similar problems.
Thinking about it some more:
now() executes at the default scan class rate (typically 1 s).
now(0) executes once on load.
now(1234) executes every 1234 ms.
You could probably use now(0) so that it executes once on load and let the polling rate dictate how frequently it updates after that. (I've never tried it this way so check that the end date actually updates every 300 s.)
Anytime you have tags and/or parameters within an Expression that changes values, it will re-trigger the expression regardless of any configured polling (named query, scan classes, tag groups, etc)
Those query parameters are not simple ones. I would make them their own custom props or tags. Then provide them to the query binding, it will make debugging easier and will allow you to reuse the values.
If the parameters are the driving factor for the query, set the query’s polling to off so it only runs when the params change.
Thanks for all the help. I applied 2 of the recommendations:
