Is there a way for Ignition to internally limit & reject Sessions and/or Pages? During some benchmarking there were enough pages open that it crashed the gateway, and then went into a cyclic cycle of restarting, trying to handle all sessions, and then crashing again. I could put a script on session startup that checks for a session and page count and redirects to a view with no data (barring that session startup scripts occur before any of the "old" views are requested to be loaded again), but I'm wondering if it can be handled by Ignition before any of that, or if it's planned for a future release?
You can ask Sales for a limited license, which the platform will enforce.
Is the limit configurable in the gateway at all, or is it strictly from the license?
No, mostly because I don't think anyone has ever asked us for it before. As of 8.1.23 you can terminate sessions from the gateway web UI: Ignition 8.1.23: UDT Hierarchy Tool, System Cleanup Properties, IdP Password Reset Support | Inductive Automation
That capability means there's some kind of hook in the backend. In theory, you could script something that would attempt to terminate sessions based on your criteria. Such a thing would be officially unsupported (the license parameter is the only currently supported mechanism) but doable.
Understanding it would not be officially supported, are you able to point me in the direction where I could find that hook?
And I take it the license configuration limits sessions, not pages?
PerspectiveContext has a getSessionMonitor: PerspectiveContext
Once you have it, you can find a session by ID: PerspectiveSessionMonitor
Then the InternalSession can be asked to close (or to close a particular page, in theory): InternalSession
2 Likes
Found that Session Events + system.perspective.getSessionInfo(), closePage(), and closeSession() can do what I need.
1 Like
Are you able to share some of your benchmarking results ? Server spec and how many sessions/pages you had open etc ?
It would be hard to compare against my benchmarks because our views would vary, and I can't quite share the views I used.
But my steps to produce this were:
- Picked a page with what we thought were the "heaviest hitters"
- Duplicate that browser tab x times across multiple users
- Watch gateway resources
I'm sure there are better/more consistent ways of doing this.
A note though: we are using Sepasoft, so after the Ignition service startup, the Sepasoft modules are starting. Incorporated system.mes.isProductionStarted() in Session Events/Startup and closing the session if production isn't started. I haven't tried putting the server into the "restarting loop" after implementing that, but I figure it's likely since x pages crashed the server, and they are going to try again once it starts back up.
YMMV
Consider splitting your server into frontend/backend duties. I/O and production critical activities on the backend server, and general users on the frontend servers. Expose the I/O to the frontend via remote tag providers. Since Perspective has to run all customization on the gateway, it suffers much higher loads than Vision as numbers of users climb.
3 Likes
Felt like this was going to be necessary but this "discovery" is fast tracking that. I'd say it's vital for any system that is critical (MES, for example).
This was always* available via scripting though. You can terminate sessions with system.perspective.closeSession
Edit: I see the OP already found this