What is the most number of simultaneous perspective sessions you have seen? Answers can be from ignition developers or IA staff from testing results.
Talking about on a single front end gateway.
Thanks,
Nick
This is a bit of a loaded question because page complexity and data needs will make a big difference.
I asked QA what they do and the answer was they don't look for a max, but they load test up to 100 concurrent sessions and if it fails before that it's a regression.
A quick poll in support says they've seen 140-150 sessions. I pinged sales engineering but no answer yet.
Hopefully others will chime in.
3 Likes
Just interested to see. Reason we are asking is because we are rolling out a huge amount of screens to show performance to plan data to floor associates at the dock doors and at present we are up to 125 sessions and don't seem any appreciable strain on the gateway so we feel like we can go a lot more.
This thread could be helpful to someone down the line when they are considering how many sessions is possible.
Nick
5 Likes
it really depends, we have one server that maxes out at around 50 sessions , but the main screen there is like thousands of points of data updating every second, and a couple dozen flex repeaters, and a bit of scripting on every element, so its a heavy page
we have another server that has not so intense a project, 100 values or so with most of the work being done by tags, its at 160 sessions right now and usage is around 20%
1 Like
Yeah, I once saw a system that was only serving 3-5 sessions but it was slow because some of their in house people would drag/drop all of the tags from the PLC and trend a lot of them. I suggested they don't do that to improve performance because they were having problems. The one engineer got back to me and said he removed ~50k of the tags they were trending.
I was surprised it ran as well as it did to be honest. Regardless, load is relative to everything the gateway is doing. You just have to monitor things as you make changes to get an idea of what the system can handle.
Out of curiosity, what's the server spec?
Just an update, today we reached a new record (for us) at 165 sessions:
We still feel like there is room to run on the front end gateway:
Nick
2 Likes
Here is the spec for our front end:
Nick
Also, in relation to the topic of screen complexity vs. session count, the screen which is most populous is the shipping lane set screen. It is meant to give those who load the trucks visibility into the status of the equipment which directly impacts their work and performance to plan.
One of the key principles of this screen is that by making the volume targets more visible, they will be more likely to be met. Data quantity and size wise, it is a relatively simple screen.
The details are very simple and cartoon like so that the colors can be seen from afar (usually 5-10 meters away)
Nick
3 Likes
I asked QA what they do and the answer was they don't look for a max, but they load test up to 100 concurrent sessions and if it fails before that it's a regression.
Did QA give any indication the page/view load on the 100 concurrent session testing?
What aspect of the load do you want information about? What we have found is for very simple pages and a login of 100 users at the same time, CPU rarely rises above 10% and memory moving 1-2% on the Gateway itself.
Ultimately, the things that have a much larger impact on this are the perspective views and the data they are requesting. If the page is creating thousands of subscriptions, this will greatly impact how any given page will impact the Gateway itself depending on the amount of data that has to be generated to keep data up to date via the websocket connection.
The client the screen is running on will typically play more of a role in what can be handled in a Perspective view as the following needs to be factored in:
- Network performance for the websocket connection.
- The complexity of the view being rendered (nested views, bindings, styles, etc. all play a part in this).
- The CPU & Memory of the client and the browser it is running in.
1 Like
Here’s a metrics snapshot from a central gateway running a variety of projects (all tags over gateway network from on-site Ignition servers at various locations). It’s not a lot of sessions, but they’re mostly on the heavy side (detailed plant control views). All Designers run from this gateway with project changes tested and then pushed out via EAM to local servers that run production-critical clients while other users run the same projects from this central gateway.
I’m curious how some of these metrics look on a number of sessions basis for other (perhaps lighter) projects.
Performance page:
VMWare server specs:
I’ve seen about 90 perspective and 130 vision from memory. Ill have a look next time I'm connected as I'm trending the values.
We've had some issues with performance, but I think we’ve finally got it sorted with ia support. There have been a few memory leaks fixed due to remote tag providers that weren’t releasing subscriptions when they were marked for death. So the frontend kept falling over every week or so due to memory 
