New to the forums and looking for some help with poor performance in our Perspective project. Our project is being used on desktop and happens in Chrome or Firefox (haven't tested the Perspective desktop app)
We're noticing that if we have a tab open to one of our Perspective pages - none in particular - that switching to another tab for a while and navigating back causes CPU to spike on the client browser. If the tab has been out of view for a while, say 1hr, coming back usually results in the page becoming wholly unresponsive with data looking frozen and warnings from the browser such as asking to wait or exit.
Is there a setting in Perspective or on the gateway (or JVM wrapper settings in ignition.conf?) that can cause e.g., streaming data to be cached until the page comes back in to view?
Some other details of our setup and symptoms:
This page freezing issue is prevalent even on our test system with 2-3 concurrent active users, though reported more frequently on our live system with 20-30 concurrent users per HMI gateway.
This seems to happen mostly on pages that have a lot of (embedded) views - mostly a mix of labels, dials, bars, and sparklines all with tag bindings. If the page has just, e.g., a mix of 20 labels and dials with tag bindings, this doesn't seems to be easy to replicate.
Gateway logs on our live system show a fair bit of 1006/timeout WebSocket errors and 'received prop sync for missing view' warnings - is this related by chance?
Wireshark packet captures show data streaming even when the tab isn't the main one open. Coming back to the tab and observing things freeze, we eventually see a lot of [TCP ZeroWindow] errors and subseqeuent TCP RST's suggesting that the browser is struggling to flush buffered data. So perhaps this can be remedied by disabling caching when the tab isn't in view?
I know this is a wall of info but definitely curious if anyone has seen something like this and what can be done to improve performance.
In the gateway, do you monitor performance? How much RAM do you have allocated, Perspective I would hope 4 GB at absolute minimum, more if you have multiple clients and you say you have a couple. Remember all scripts run ON the gateway. 20-30 users should require a beefy server. But if it is happening with just 2-3 users - I suspect an issue with the way the view is setup.
What are the bindings like - do you have a runScript in any of them? Do a control+F for runScript and see if you have it in any bindings, poor usage of it can cause massive performance issues if you're using it to do something complicated.
Do you have use property changes somewhere? Poor scripting on a property change can accidentally induce an infinite loop (property change script A causes property B to change who's script causes property A to change and so on) and this can crush your performance as well.
I would first look at all the scripting and bindings. Perspective is certainly more of resource hog but if it really was just tag bindings, then with a sufficiently strong gateway I wouldn't expect too many issues - I am working on a project with 13 always on perspective HMI's, all just tag bindings, and it basically never goes above 1 GB of ram usage.
Thanks for the suggestions. Our test system performance looks good. We have it running on a VM with 4-cores and 10GB memory allocated for Ignition. Garbage collection looks normal (sawtooth) an typically doesn't go above 6GB used. This is a fairly large project and there is a lot of customization to each view in terms of styling and functionality (e.g., bindings on style props). This is the system with 2-3 concurrent users.
We don't have runScript in any of the tag bindings on the pages we're seeing freeze after tab switch. We do have property change scripts on some properties but when viewing a page live, we don't really see any issues. It's when we switch away from the browser tab (e.g., to go look at google.ca or even another Perspective page on the same session) that we see this issue when coming back to the page/tab after a while.
You mentioned you're using embedded views... there were issues previously with nesting them too deeply - do you know approximately how many levels deep you use embedded views? For instance, you could be repeating a template view that has an embedded view to another view, and that embedded view has multiple other embedded views, and so on.
I think this was fixed - it might be helpful to know what version you're on. We nest 2 to 3 levels deep without any issues, at least that we've noticed.
The most important aspect to all of this has actually not been made clear. How much data is being displayed in the View in question?
Some users experience similar issues when they are streaming large datasets (Named Query bindings which return thousands of rows), have polling Alarm Table(s) for very busy Gateways, and/or have many complicated SVG based components (these components regularly receive data AND must re-draw quite often).
Additionally, your version could play a large role in this. There have been documented issues with components in older versions where we used older versions of AmCharts as a third-party library to render some components (Pie Chart, maybe Sparklines, and both Gauges and Simple Gauges). So an older version of Ignition might be prone to issues when displaying these components in some situations.
On one of the main pages we see freezing on I counted about 40 tags being displayed and about 130 in total including tags not being actively shown e.g., in a carousel component. This is a mix of labels (mostly), dials, and about 1-2 bar charts. The page is really just a wrapper that contains many embedded views, pretty much one for each tag binding. The embedded views in question are often 1-4 embedded views deep before reaching just a component. Quite a bit of our project is structured around views that serve as templates.
We do have pages/views running named queries returning potentially 1000+ rows, but in our test system they're not actively being viewed when we trigger this issue. Our alarm tags are on another IO gateway and the HMI gateway is subscribing to and not polling for alarms. We're not using SVG based components - unless the icon component counts.
All of our gateways are on 8.1.28 standard. I don't see any mention of AmCharts fixes after that version but I can try on 8.1.38 on our development system and see.
Fairly certain it doesn't matter if they're being displayed or not. If they are on the active view they're being processed. Not that 130 is a massive number of tags to be active. I haven't done any testing to verify this, but I believe that this is true even of things hidden behind a tab. Willing to be corrected on that though.
This is definitely not helping performance, at least not when the view is loading/refreshing. I know that @YF129701 says they have nesting up to 3 levels deep, but this has been a known performance hit for some time. Recommendation is to avoid nesting over 1 level. A few here and there will not hurt, but get many of them on a view and you'll take a hit.
Are there any other applications running on the Gateway?
Otherwise, here is a "generalized list" of things to look for when looking at performance in perspective: