What is the number of concurrent user sessions or logins that would be allowed or handled by Authentication Services and vascache-ipc-timeout information. (4265492)

What is the number of concurrent user sessions or logins that would be allowed or be handled by Authentication Services?

What is the effect of setting a very high or very low value to the vascache-ipc-timeout setting?

There is no single number, it depends on system and network and AD speed.

When auths starts failing, aside from defects/issues, normally the response is to increase the vascache-ipc-timeout.

Vasd is a lot faster of course with one account logging in over and over vs a lot of unique accounts.

There have been examples of stress testing where limits have been pushed with 15000 users, trying to auth them all, through 500 simultaneous jobs. ( so no more than 500 pending auths at one time. ). It worked with a fairly large vascache-ipc-timeout value of 120.

This is a KB article on the vascache-ipc-timeout setting that is being referenced above:

https://support.oneidentity.com/authentication-services/kb/254212/

Information on the possible effect of setting extremely high or low values for the vascache-ipc-timeout setting:

The vas-ipc-timeout setting is correlated to how long the NSS and PAM module wait for information from vasd. ( And how long vasd waits talking between itself. )

If the vas-ipc-timeout setting is set very to a very low number normal activity might fail to complete. Asking, for example, to update a user could take a couple seconds ( If it's the first request in a while, vasd has to establish credentials for AD, establish the sasl ldap connection, then do the queries, process it, process group memberships, and write it all to cache ). If the timeout is set to 1 second it could easily report an error because it didn't wait long enough.

With a very large value for example 120, the issue that could be seen is when something does go wrong it can take a very long time to time out. For example with invalid DNS entries. The request will time out regardless of what the timeout is set to, just the larger values take longer to return.

10 seconds should be fine for most normal situations and there shouldn't be issues setting it up to 20 or maybe even 30 for a general roll out to systems, but above that it's best to reserve the high values for heavily loaded systems only, for example ones that have more than 50 logins a minute.

Also of note is the fact that some things scale off the value, for example during a flush the value * 5 is used as a timeout due to the potentially large amount of work that is done during a flush.