Simultaneous Logins
Luminis 4 has a default concurrent login limit of 15. Does it mean that only 15 users can login simultaneously at a time? What is the unit of time? seconds?
What happens when more than 15 users attempt to login? Will the remaining users get a failure message or will be put in a queue?
concurrent users
This is a question we have asked of sungard but have been unable to get a definitive answer. We used to hit this limit quite a lot when we were on Luminis III in non parallel deployment mode, the user would see a message which says "Too many users, try again later" we eventually modified this with instructions to get direct access to our external systems. Our environment was at it's limit in terms of performance and a login would take up to a few seconds, thus increasing the likelyhood that more than 15 people were attempting a login.
We are now on L4 with PD and we hope not to see the issue again. However, this parameter can be useful if you need to restart your entire environment under load, you need to minimise the load on the servers as they start up so reducing this parameter will help your system get up and running.
David
Simultaneous login
I got the definitive answer from SunGard and here is my "non-technical" explanation: this setting controls how many users can be going through the login process at one point in time. Think of the login process as a bouncer at a club entrence. To get into Luminis you need to go through this bouncer. If you set it to 5, the bouncer only checks 5 users' ID (i.e. the authentication) at a time. So if 6 people try to login at the same approximate time, then the sixth person will get the message saying that there are too many simultaneous logins.
The default setting for the max concurrent logins is 15 and 15-20 is the SunGard recommended setting. Depending on the time (start of semester or Web registration period), you might want to change it to a higher number but remember to change it back to the suggested setting afterward.
Hope this help.
Arion
Concurrent Logins & ns-slapd
Hello! My name is Michael Gregorowicz from Wayne State University in Detroit, MI. Recently we've been brushing up against this issue and I wanted to point you guys in the direction of the oft-overlooked ns-slapd instance that comes bundled with Luminus!
If your organization is anything like ours, you might have absolutely no data retention policy. Over time this might lead to your ns-slapd instance overgrowing the default configuration settings. If you're noticing your ns-slapd process hovering right around 100% of one core/cpu especially during database writes (from Banner integration components), this might be the culprit.
In addition to tuning the "bouncer" number (I like your analogy, Arion), you need to make sure that the authentication back end, ns-slapd is taking advantage of available resources to handle the additional load. These configuration options are specified in the dse.ldif file inside the ns-slapd instance allocated to the Luminus application. Take a look at the caching portion of the ns-slapd manual here:
http://docs.sun.com/source/816-6697-10/caching.html
Increasing the value of: nsslapd-cachememsize will prevent heavy disk thrashing when writing to a large id2entry.db index file.
Increasing the value of: nsslapd-cachesize will allow reads to happen more quickly.
Increasing the value of nsslapd-dbcachesize will make fetches from the actual db files quicker when the index & entry caches aren't hit.
In addition, if you have adequate CPU resources available on your hardware, feel free to increase the nsslapd-threadnumber to something higher than the default '30'.
Keep in mind, you should only increase these settings if you have available hardware resources. You won't be able to eke out performance from an already taxed machine, but if you're like us and have a juggernaut box sitting mostly idle while your users can't do something simple like log in, these changes may be for you.
Good Luck!
-Mikey G
Issues
Hey Mike - thanks for the suggestions. We ran into issues the past two days where our portal crawled to a halt. We started receiving 503 errors . Today we noticed that just restarting the LDAP cleared up the issues. With Sungard supports ok we've increased our LDAP threads and cache size. Hopefully this resolves our issues. We had the same symptons. Resources on the box looked fine, yet nobody could login and the portal was extremely slow.
attribute values
Mike,
What did you set your values to for the following attributes in dse.ldif ?
nsslapd-cachememsize (ours is set to 10485760)
nsslapd-cachesize (ours is set to 10485760)
nsslapd-dbcachesize (ours is set to 25000000)
Where is the "nsslapd-threadnumber"? I couldn't find that in dse.ldif.
Attribute values
I also have been unable to find "nsslapd-threadnumber".
My nsslapd-cachesize: -1
nsslapd-cachememsize I am going to take from 10485760 to 100485760 (ten times as much.
nsslapd-dbcachesize is going to to 250000000 from 25000000 (also ten times as much)
I will let you know how things go after I restart tonight.
Charles
Multiple
After looking some more I found multiple instances of nsslapd-cachememsize. 6 to be precise. I'm guessing each one should be upped by the same amount making it about 600 Megs for all 6 (at 100485760 per instance), or should I add the zero at the end? (104,857,600)? My largest id2entry.db3 is 1,060,000,000 bytes (user root).
Edit: I think will start by increasing the user root and pab entries, they are my two largets db's.
Going try taking user root to 500M +- and pab to 100M. Crossing my fingers, and toes and eyes...