Slow system.nav.swapTo (increasingly slower over time)

Ignition
,
1

Hi,
I have a performance issue. Maybe someone has some idea how to troubleshoot or fix this.
My customer experience slow .swapto operations.

The performance is ok on a freshly started Vision client. After some days the time it takes to navigate between main windows increases to 5->10 seconds.
By restarting the client, everything seems snappy again.

ref the attached photo, the client having the issue is running 4 desktops.
-There are also 2 other clients running without the same issues. But with slightly different usage patterns. Only 1 desktop pr client and possibly less swapping between pages.

-Main windows having caching set to auto. I have been navigating between all pages on a freshly restarted client without performance issues.
-Clients have 512mb allocated memory on the gateway

What could possibly explain such behaviour
Running Ignition 8.1.9

image
image1920Ă—1051 124 KB

2

2 things spring to mind:

  1. Are you opening or swapping main windows (you should be swapping)? (if you display the result of system.gui.getWindowNames() somewhere called from a button, how many windows are open when it’s slow?)
  2. are you calling system.alarm.queryStatus() from your GUI anywhere? (queryStatus is the devil, especially for Vision when calling from the GUI and will kill your clients, and won’t be great for your gateway either)

Nice looking screens though, from what we can see :slight_smile: clean is good!

1 Like
3

Give your clients a larger memory allowance. (It doesn’t consume memory on the gateway. Vision runs on the client machine.) 512MB is pretty tight for complex graphics.

3 Likes
4
  1. I am swapping. only one window returned with system.gui.getWindowName()
  2. I am running system.alarm.queryStatus() from within a tag change-script. This will execute on the gateway only? yes?
    Thanks for the feedback, yes clean is good :slight_smile:
1 Like
5

Ok, will do.
I actually have misunderstood where memory is allocated regarding Vision clients :wink:

6

I'd move this out of a tag change script and into a gateway timer script if you can. No impact to clients, but it'll avoid missed tag change script events if the query takes too long

1 Like
7

Ok, will do as well

8

As long as it’s a gateway tag. If its a client tag with a client tag change script, it is executing on the client.

1 Like
9

True. I actually recently found 27 vision client tags in one of my OOOOOLDDD projects when I first started Ignition all using runScript expressions calling queryStatus… I thought I was so smart, but I was definitely at the peak of Mt Stupid. I also always wondered why the clients were a bit sluggish and the gateway was being hammered by hundreds of alarm queries per second across the GAN :roll_eyes: smh

image

5 Likes
10

Thanks for the clarification. Its a gateway tag

1 Like
11

We all have those.

I found a problem in something I wrote a long time ago that was deadlocking the database because I didn’t know about SGAM contention and it was using a table variable in a query that was called by multiple clients.

12

There’s also just some general memory leaks in Vision that are fixed in later versions. I’d recommend updating in addition to the other advice in this thread.

2 Likes