A scan class with a duration that isn’t near zero is usually one with Query or DB tags that are taking non-trivial time to execute. We generally recommend you move these to their own scan class.
These do not affect the update of OPC tags belonging to the scan class unless you are using OPC Read Mode. For OPC tags the scan class rate is just a hint used to tell the OPC server what sampling interval we want when subscribing. There is no execution or polling or anything else done by scan classes for subscribed OPC tags.
They are actually non trivial tags (expression) as you pointed out. There is nothing wrong… I was just wondering what Ignition does if the avg. duration exceeds the scanclass rate. The scanclass is a direct one, whis subscription mode.
I have another scanclass (with approx. 10k tags, subscription, 500ms rate, all opc tags, duration around 30ms)… the OPC Server is an Ignition OPC server on another computer. the CPU load currently around 40%. If I lower the rate for this scanclass from 500ms to 100ms, the CPU load ramps up to 100%. So the subscription rate must have some impact on the cpu cycles of the OPC Server computer. Interesting thing: going from 500ms up to 1s or 10s has no perceivable impact on the load, going below 500ms on the other hand, affects the cpu load a lot. 250ms: cpu load 40% -> 90%. Tags in this group don’t change frequently. But when they do, they might trip (1->2->1) in a matter of a fraction of a second, so I try to lower the rate as much as possible to catch this events and issue an alert.
Sure, lowering the rate is not free of consequences for the server. It will have to do more work. But that increase in work is not caused by an increase in polling requests from the client, it’s because now the server is polling its underlying devices and running its subscription polling interval 5x as fast.
If you want to see the impact of the subscription load on your (Ignition local) OPC server, go to the Devices’ status page, and examine the details for the device in question. Those load factors are directly related to your scan class rate.
To wrap it up, I would like to find out why the scanclass rate pushes cpu cycles up so badly when you go below 500ms (I know this is not a magical number…) but still when going from 10s to 1s to 500ms there is no perceivable impact. Below that, cpu cycles go up to 90% at 250ms and hit the roof at 100ms. Maybe there is some heavy gc going on and the jvm just can’t cope with it anymore… I have 10k+ datapoints, but no polling to the devices.
It’s most likely because in 7.9.7 a scan class rate is used as both the requested Publishing Interval of subscriptions and the Sampling Interval for items belonging to that subscription.
Publishing Interval is essentially how fast a subscription periodically “evaluates” itself to see if any of the items that belong to it have data changes queued, which it gathers and reports to the client in a batch.
Sampling Interval is per-item and is a request to the server to sample the underlying data source at this rate. Not really relevant in your case.
The CPU usage is probably just the server struggling to run that subscription faster than 500ms.
In later versions of 7.9 the requested Publishing Interval may end up even faster than the rate. The idea being that with, e.g. items being sampled at 1000ms, you might want a Publishing Interval of 500ms so that you don’t have to wait as long to receive the value for an item that sampled just after that last Publishing Interval elapsed.
In 8.0+ the requested Publishing Interval is configurable.