How to Set OPC UA Monitored Item Queue Size

Back to Blog

Work Out How Many Samples Fit Between Publishes

The queue holds sampled changes waiting for the next publish. So the number you need is how many samples the server can take in one publishing interval: publishing interval divided by sampling interval. If you sample four times faster than you publish, up to four changes can pile up between publishes, and a queue of one keeps only one of them. The rest are discarded and, unless you set the flag, silently.

This ratio is the whole calculation. A queue smaller than the ratio will drop data on any point that changes every sample; a queue larger than the ratio wastes memory but loses nothing. Because the settings interact, size the queue only after you have fixed the sampling and publishing rates - see OPC UA subscriptions and monitored items for how those two rates relate.

Choose the Discard Policy Deliberately

When the queue does fill, the discardOldest flag decides which sample dies. Keep oldest-discarded, the usual default, when you care most about the latest value and can tolerate losing intermediate steps: a level trend where only the current level matters. Keep newest-discarded when the sequence itself matters and the earliest unreported change is the one you must not lose.

For most process telemetry, discarding the oldest is right, because a monitoring client wants current reality. But for anything you are integrating or counting - a totalizer, an event stream - think hard, because dropping intermediate values corrupts the total. If sequence integrity is critical, a queue that never overflows is the only safe answer, which means sizing it to the ratio above with headroom.

Read the Overflow Bit to Confirm Nothing Was Lost

OPC UA sets an overflow indicator in a data change notification whenever the queue filled and a value was discarded. This is your ground truth: if the overflow bit never sets, your queue is large enough for the real traffic, whatever the theory said. If it sets, you are losing samples and the trend has gaps you cannot see any other way. Treat a set overflow bit the way you would a bad quality flag - see the OPC quality code substatus - as the server telling you the data is not complete.

Log the overflow occurrences during commissioning under realistic process activity, not a quiet test. A queue that is fine at 2 a.m. can overflow during a startup transient when everything moves at once. Size for the worst burst you expect, and the overflow bit staying clear through that burst is your acceptance criterion.

Verify With a Worked Example

Say a flow value is sampled four times per publish - a quarter-second sampling period against a one-second publishing interval. A queue of one keeps one of those four fast changes and discards three. Set the queue to at least four to keep them all; set it to five or six for headroom against a jittery sample clock. Push the flow through a fast swing and confirm the client sees each intermediate value, not just the endpoints.

Now confirm the overflow bit stayed clear through that swing. If it set, raise the queue and repeat. If it stayed clear, you have proven the queue against real motion rather than a datasheet number. Because the exact right size is site-specific, this measured verification is the step you cannot skip.

Common Mistakes

The default queue size of one is the classic trap: it silently downsamples every fast point to the publish rate, and because there is no error, nobody notices until a missing pulse causes a bad total. The second mistake is ignoring the overflow bit, which is the only signal that samples were dropped.

A third is over-sizing every queue to a huge number to be safe, which balloons server memory on a large subscription for points that never change fast. Size to the sample-per-publish ratio with modest headroom, not to a round large number. And do not use a deep queue to paper over a publishing interval that is simply too slow for the process - fix the cadence first.

Frequently Asked Questions