Performance Issue over VPN

Ignition
1

I am having a severe performance issue when I try to run a client over a VPN. I had posted on this previously and was directed to check firewall etc. I have done that and seen some improvements but only marginal. I have spent the last couple of days testing and troubleshooting and I think I have the issue narrowed down to indirect tag binding. Let me explain.

First off, when I say severe performance issues, I mean the client is unusable. I have screens that are only subscribing to 70 tags that take 10 minutes to update. Also during this time the entire application slows down, if I hover the mouse over a nav link it takes 10 to 20 seconds for the overlay boarder to appear. Then when I click the link, it is another 30 seconds to open the next screen. This problem also gets worse the longer the client app is open.

So that is the behavior…this is what I have discovered.

  1. This behavior only occurs on screens that have indirect binding (which my application uses extensively). I have one screen that I did all direct bindings on (about 70 subscriptions). If I open the app and go straight to that screen it updates at least once a second, I can go to the history screen or alarm screen (very few sql tag binding) and they also work great. But then if I go my screens with the indirect bindings sluggish behavior and 10 minute updates. If I go back to the directly bound screen quickly it will work great as well, however, if I stay on the indirect screens for too long then my directly bound, historical and alarm screens also become wickedly sluggish. The only solution is to close the client and restart.

  2. The problem seems to be worse on screens that have bindings to a dynamic property on the root container.

  3. The client app at some point/randomly does not release tag subscriptions when you close a screen. (This behavior is much worse with the client is running Java 6 but also occurs on a Java 7 client.)

  4. This behavior is consistent for several internet connection types to the server (cellular mobile broadband, 10 mbs cable modem, etc.)

If anyone has any insights or ideas they would be greatly appreciated. We have been working around this issue using the mobile app on a chrome browser, but with Java6 at EOL we will have to stop using that solution.

Sorry I almost forgot Ignition server stats:

Windows Server 2008 (all updates current)
Java 6 (all updates current)
Ignition ver 7.5.4
20meg up/down fiber connection at the server end.

Thanks

Wes

2

Yeah, this doesn’t sound right at all. Any chance you could send us the project? I suspect you have a binding loop. How’s the CPU usage on the client look?

3

Sorry for the delay, I have been on the road for a few days. If you give me a ticket number I will upload the project to you.

4

I PM’ed it to you.

5

Carl,

Have you had a chance to look over the project?

6

Just circled back around to this. Any hints as to which windows in this project I should be looking at? Also, I might need a gateway backup, since I’ll probably need your tag configuration to troubleshoot this.

Alternatively, if you want to set something up so that I could launch the client from here, that would work too.

7

The “Water/Res4” screen would be good example. I am out of the office the rest of this week but if you would like to see the system live, we could set something up the first of next week.

Thanks for your help on this.

8

Nothing’s jumping out at me. Let’s plan on getting together next week so I can take a peek at the actual system.

9

Sounds good Carl. I will call in on Monday.

Thanks

10

Carl,

Thanks for all your help the other day. I have modified a couple of my screens for testing and so for it appears that getting rid of the queryAlertStatus with the path wildcard is making a huge improvement. My method for solving this deviates a bit from the options we discussed so before I replicate through the project I wanted to get your opinion on my method.

I created a client expression tag:
Data Type = dataset
Expression = runScript(“system.alert.queryAlertStatus(activeAndUnacked=1, activeAndAcked=1)”,1000)

That client tag is then bound to a dynamic property on the root container.

Any object that need the alarm state of a group of alarms has a dynamic property bound to the root container dataset with the following property change event:

if event.propertyName == "AlmList": stationName = event.source.parent.StationName pyAlarm = system.dataset.toPyDataSet(event.source.AlmList) activeAlm = 0 unAckAlm = 0 for alarm in pyAlarm: if stationName in alarm['Path']: activeAlm = 1 if alarm['Acked'] == 0: unAckAlm = 1 event.source.NumAlm = activeAlm event.source.NumUnack = unAckAlm

This lets me keep this dynamic without having to create an alarmActive and alarmUnAck memory tag for every alarm group I want to use.

So far my only concern is the property change event is firing every time my expression tag updates (whether the alarm dataset has changed or not). I am guessing that when a bound dataset is updated the dataset is deleted and recreated each time which causes the property change event to fire. Do you think this could cause a performance issue if I had say 30 or 40 of these alarm group binding on a screen? Would I be better off, performance wise, to just run a gateway script that queries the alarm status and updates a bunch of discrete memory tags?

Thanks again for all your help.

11

I’m not too worried about the property change scripts, but I do not advocate this approach for another reason. The client tag’s expression is also going to execute on the UI thread, which was your problem in the first place. You’ve consolidated the number of queries, but I still would rather that expression not run on the UI thread. You really want to run it in a background thread if you’re going to have it client-side, which would mean running it in a client timer script.

12

Thanks Carl