We have an Ignition application with some (Main) Windows having many (100-300) “images”. The “images” are typically the multi-layered Template Instances where each Template itself may consists of several components (3-10), including one or more Template instances (In fewer cases, however, the “image” may just be a single built-in Ignition component).
When we developed the application in the Ignition Designer, there wasn’t any issue with the speed for loading/opening the Windows with many “images”. At worst, the Windows would be loaded/opened after 2-4 seconds of loading.
However, as we deploy our application, our clients complaint on those Windows as sometimes it might take 20-60 seconds (or even unresponsive) when they try to open those Windows. This is not only happening when our client’s PC is old (some of our client PCs are newer and more powerful, but some are not), but also when our client’s PC is new. When they open a Window without many “images” the speed of the loading is acceptable, but not so for the Windows with many “images”.
And so, we look for solution to speed up this loading.
Some of questions we have:
How do we know how much data (kB/MB) needs to be sent to the client side per Window? Is there any way to monitor this? When we open the Task Manager, the Network Tab only shows the overall Network activity of Ignition (java.exe) over time - not individual Window. We would be happy if we can have this info for our investigation
What are the possible reasons for this slow/unresponsive behavior? Bad network? Too much data per Window? Why when we developed the application, the speed was of no issue, but when we deploy the application, the speed becomes the issue for old and new client PCs alike?
We realize that we use many multi-layered Template Instances for the application. We are wondering if this could be a possible reason for the slow response. Is this true? How much slower can a multi-layered Template Instance be compared to, say, single (built-in) Ignition component or single layer Template Instance (where a Template consists only (built-in) Ignition components and not another Template)
Are you using anchored or relative layout? The designer never scales the window size, so relative layouts always preview at 100% scale. Runtime does scale the relative layouts, causing all images to be rescaled, possibly only slightly. Try copying your project to another, and going through the whole thing changing all layout to anchored. Then test the speed.
We tested to change the layout into anchored as you suggested. Unfortunately, it didn’t help much - there wasn’t any difference in timing. Could it be because there isn’t much different in the size of the anchored and in the relative in the first place in our application?
Any other idea? Can we know how much data per Window is needed?
Ignition serializes windows in the designer and unserializes them in client. You could get an estimate of window static memory size by comparing the sizes of a partial exports of the project for specific windows. But keep in mind that java memory consumption is also dependent on “churn” as dynamic objects are created and discarded, then garbage collected. If your project has different memory allocation (project setting) for designer vs. client, this would be significant. In the designer, memory consumption vs. allowed shows in the lower right corner of the screen. In the client, you must open the diagnostics window.
Ok, thanks for the advice to check the memory consumption based on the partial project on that window. Will try that out.
Another thing we noticed was when we opened the windows task manager, the client’s PC’s network speed is a lot slower than the server (1 kB/s vs 16-100 kB/s). This could also be the reason for the slow response.
I know this is an old Topic, but I came across it while searching for a solution to my own issue and thought I would share in case it can help someone else;
I have a couple of dozen windows that all have about 40 Multi Layered Templates. The templates themselves I’ve tried to optimize by not directly using UDT’s, but using indirect tags instead.
I found that a window would take upwards of 10 seconds to get fully loaded. Templates/graphics would show up, sit for a few seconds and then go thru their process of loading/connecting all of the tags.
Long story short(er) I found that if you use internal properties to load any values (I was calling a named query) they appear to get called based on the project default polling rate. So the template will load, and then (by default) 5 seconds later it would execute the internal property (query) and then finish loading all of the other info.
To fix it I took all of the internal properties and moved them to template parameters. I ended up having to re-attach the queries and expressions, etc in the vision window. But it dropped the initial load time down to less than 2 seconds, so it was worth the re-work.
Consider also setting queries to “no polling” wherever you can. You can deliberately cause a refresh when needed by using system.db.refresh(). That can dramatically improve application responsiveness.