Concurrent Sessions versus Named Users
Posted: Fri Dec 18, 2009 9:28 pmNow that I've set myself up as a user in addition to the administrator account, I see when I run the active sessions list it totals up the active sessions.
Bo mentioned to me that in practice a license for 5 concurrent users, depending upon usage, might support 20 - 40 named users. But I don't see where the system is closing sessions (as occurs in DAW's WebApp Server product). DAI is working like our SageCRM system works, i.e. it keeps an active session going as long as the user is logged in. But Sage has a global setting for maximum idle session duration, after which it ends the session, freeing up that seat. (It would be better if that session limit were user-specific.)
I couldn't find a session time-out parameter to limit the length of time a user can remain on the system. We can hardly get users to log off of windows and shut their systems down daily. Getting internal users, let alone external customers, to exit an application -- especially in a browser window where they are accustomed to it being a static connection (not that they understand it in those terms), is unlikely. That's going to present a real challenge in deploying a system as extensively as I'd hoped as it will drastically up the ante on concurrent users we'd need to license. We routinely have 80+ internal users logged into our systems. But 80% of the time, probably only 20% are generating i/o.
Bob
Bo mentioned to me that in practice a license for 5 concurrent users, depending upon usage, might support 20 - 40 named users. But I don't see where the system is closing sessions (as occurs in DAW's WebApp Server product). DAI is working like our SageCRM system works, i.e. it keeps an active session going as long as the user is logged in. But Sage has a global setting for maximum idle session duration, after which it ends the session, freeing up that seat. (It would be better if that session limit were user-specific.)
I couldn't find a session time-out parameter to limit the length of time a user can remain on the system. We can hardly get users to log off of windows and shut their systems down daily. Getting internal users, let alone external customers, to exit an application -- especially in a browser window where they are accustomed to it being a static connection (not that they understand it in those terms), is unlikely. That's going to present a real challenge in deploying a system as extensively as I'd hoped as it will drastically up the ante on concurrent users we'd need to license. We routinely have 80+ internal users logged into our systems. But 80% of the time, probably only 20% are generating i/o.
Bob