So we are trying to create a template project in perspective for suppliers to use.
We are using a lot of embedded views treating them similar to the template functionality in vision. So for example there is a button with a specific binding and a description for that button and this was created as a view and the input parameter will impact the binding in the button.
There is one pop up with 31 of this buttons so 31 embedded views. We are doing tests but we can’t replicate the full integration a supplier will have, so we can’t see the full impact of 60~70 projects running from the same gateway like this. Not saying all of them will have the 31 embedded views always opening but what is the optimization on this? Do you guys think we might have issues in the future?
I currently run around 150 perspective sessions on a single gateway simultaneously. Many have embedded views, flex repeaters with ~100 instances, etc. Really it comes down to your hardware.
Of course, you can overdo it with embedded view nesting, but Ignition can handle a lot with good hardware. I think right now, I'm running 12GB and 4 processors, which will be increased soon.
Note that some people break up a gateway into a frontend and backend gateway split to handle heavier loads to bolster performance.
Do you know the impact of using flex repeaters vs not using them? The view I described above was not using flex repeaters and I just want to give the team feedback based on performance or using it vs not.
A flex repeater will work. I always use a repeater when replicating the same view multiple times, it is so much more maintainable than individual embedded views.
Generally a wide number of embedded views isn't a concern but when it's a deep number then it starts causing problems. 31 buttons on a page is fine. 5 buttons on page A, then pageA embedded in pageB, then pageB embedded in pageC is where you start having to consider issues.
The flex repeater, especially set up as a grid repeater, is perfect for buttons panels like this.
Though one caveat to that is you should only be passing simple parameters into those buttons. So the tagpath for the tag and then the button view then uses that tagpath and does its own bindings appropriately. Don't pass a full UDT into each button in the repeater, that would not be good.
My experiences have been similar to @dkhayes117 assuming your screens are architected based on best practices.
The most important thing to consider with the type of screen design you are describing is to optimize your bindings. You generally want to have your tags organized either in folders or UDT instances and handle all your bindings on the embedded view by passing in a partial tag path and indirectly binding the elements on your view using the tag path that you pass into the view as a parameter. Indirect bindings are really fast.
NEVER use the tag() expression function on a visualization screen. If you need to look at more than one tag in a binding, create custom properties that are populated from indirect bindings from the tagpath you took as a parameter. Then reference those properties from an expression binding.
If you follow these practices you should get decent performance and your screen architecture should be scalable.
If you find out that you’re having performance issues from too many sessions for the server to handle and you can’t add more resources you can pivot to a scale out architecture. You rarely have to do that. Search documentation for “scale out architecture” for more information about that. I think 80 sessions is unlikely to put you in a situation where you need to scale out.
Flex repeaters are generally fast. You can even generate the content for them dynamically with a script transform and still have great performance.