Perspective Alarm Status Table Performance


One of our clients has expressed concern about alarm status loading times. On the perspective alarm status table they can take over 10 seconds to load.
Upon investigation it seems that the alarm status table was returning all alarms, including cleared-acked ones. This meant to display the e.g. 3 active / unacknowledged alarms we actually care about Ignition was pulling around 570 pages of alarms.

Currently we use the{source,provider} for filtering, which according to the documentation (and network traffic) are handled on the gateway, and these are relatively quick. On the other hand, the filters which we use to filter out clear-acked alarms seem to only take place on the client (based on HTTP/WS network traffic), which would explain why so many alarm events are being fetched.

In order to try filtering on the gateway I had used a filterAlarm script on the status table - however it did not seem to be any faster. It did reduce the payload size from ~10MB to ~20KB which would imply that it was doing what I wanted - just no faster than before. I imagine that running a Python script around 10,000 times (for each alarm) isn’t particularly fast?

Is there any way to filter based on the alarm state on the gateway side for the alarm status?


In 8.1.18, more of the filtering for the alarm status & journal table will be moved to the gateway:

Final release is approximately mid June.

That sounds perfect, thanks.

Just an FYI for others.

We tested this new functionality out on a very large system we have here with >30k alarms configured (of which generally only a couple hundred would be active). The difference in data quantity transferred was like night and day. Going from a typical 29mb of data transferred on each update to mere hundreds of kB (based on the inspect → Netowork tab in the edge browser).

Very much looking forward to this next stable release…