# Perspective Alarm Status Table Performance **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [May 27, 2022, 4:36am UTC](https://forum.inductiveautomation.com/t/perspective-alarm-status-table-performance/60104 "2022-05-27T04:36:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Louis\_Whitburn](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@Louis\_Whitburn](https://forum.inductiveautomation.com/u/Louis_Whitburn)\ **Post date:** [May 27, 2022, 4:36am UTC](https://forum.inductiveautomation.com/t/perspective-alarm-status-table-performance/60104/1 "2022-05-27T04:36:23Z")
Hello 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 props.filters.active.conditions.{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 props.filters.active.states 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? Thanks ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [May 27, 2022, 2:36pm UTC](https://forum.inductiveautomation.com/t/perspective-alarm-status-table-performance/60104/2 "2022-05-27T14:36:07Z")
In 8.1.18, more of the filtering for the alarm status & journal table will be moved to the gateway: > [@Nightly 8.1 Changelogs - 2022](https://forum.inductiveautomation.com/t/nightly-8-1-changelogs-2022/54636/71): > > Weekly Changelog: 8.1.18-b20220510 Visualization 5841: Perspective Vessel: Liquid fill level not reaching actual fill line On upgrade and startup Ignition would sometimes fail to update Perspective’s SVG libraries over previous versions; this has been fixed. This bug caused the Vessel Symbol Component’s water level to appear incorrect as an older version of the symbol SVG libraries were retained. 1737: Alarm Tables: better strategy to reduce network payload, move more filtering to Gateway F… Final release is approximately mid June. ---
**Author:** ![Louis\_Whitburn](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@Louis\_Whitburn](https://forum.inductiveautomation.com/u/Louis_Whitburn)\ **Post date:** [May 29, 2022, 10:21pm UTC](https://forum.inductiveautomation.com/t/perspective-alarm-status-table-performance/60104/3 "2022-05-29T22:21:44Z")
That sounds perfect, thanks. ---
**Author:** ![Andre\_Gibson](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@Andre\_Gibson](https://forum.inductiveautomation.com/u/Andre_Gibson)\ **Post date:** [May 29, 2022, 11:13pm UTC](https://forum.inductiveautomation.com/t/perspective-alarm-status-table-performance/60104/4 "2022-05-29T23:13:27Z")
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…