Hi,

What is the exact procedure that takes place if I set the Cache Capacity as 1000 and Cache Timeout as 1 hour?

What I need to know is, if I set it as say “5000” and “Forever”, will any change of attribute at the LDAP end be reflected i.e. say I change my password and First Name after logging in to the portal once; will I be able to login again or will the name change be updated.

Thanks

One more question -

The Directory Services use a series of LRU caches (Last Recently Used) and will automatically expire any entries that either fall off the end of the list or exceed the cache timeout. So in the scenario above where you set 5000 and forever and you then change the First Name the following must occur:

Either your cached ldap entry is pushed off the end of the list, or the server is cycled. In this case the Password has no effect since we never fetch or compare or display passwords. Those are only managed in the LDAP server itself and we have no access to them.

The max value for the Cache Capacity is the maximum value for a java integer… far more memory then you’ll want to use

Ok. That means change of password will anyways prompt the user to enter the correct/latest password.

1. So then what exactly is cached?
2. Reason I am asking is because we can see a marked difference in user login times, the first time and the second time shortly after the first within the cache timeout. So we were wondering whether to increase the cache to cover all and make the timeout “Forever”

Thanks

What is cached are principals and their attributes (dn, uid, firstName, lastName and any other ldap attrs configured) as well as lists of these principals that were returned from searches.

Login in general is expensive and it’s not always clear where the time is being spent. You could use the Perf Monitor to explore what happens during the login process. If you have a large amount of users logging into your system, then you’ll want to increase your db caches. (see config/db.xml)

I wouldn’t recommend changing the timeout to Forever, but maybe to once a day to once a week.

Regards,
–mark

The db cache you are referring to would the MAXCONNECTIONS for the Worker - com.webMethods.portal.service.sql.core.BaseSqlWorker, correct?

What according to you would be the optimal settings for around 2000 users?

Thanks

My mistake, i meant to refer to cache.xml.

Our Directory Services internally also store information about users which fills up our other caches for things like role membership, custom principal attributes, etc…

As a result, we recommend that you set the Thing Cache’s maxSize (inside of cache.xml) to 5x of the number of named users just to account for directory related caching. This doesn’t include the normal portal resources (pages, portlets, etc…) that the Thing Cache normally manages.

I’d recommend changing your maxSize to around 25000 to be safe. (This requires a restart)

BTW: In 7.0 we made this cache entirely dynamic so it is no longer necessary to adjust this figure.

Regards,
–mark

Hi Mark,

Just another question w.r.t. the Directory Service fetch, is it possible to minimise this attribute fetch because all we are looking for from the LDAP service is authentication and we are not using any of the attributes in code.

Right now a first time user takes around 1 minute - 90 seconds to log in (sometimes even a time out happens). Any help in this regard?

Thanks

Authentication is a very in-expensive call (as you’ve observed). What is expensive is what we do after authentication succeeds:

• Determine Group Membership for the user
• Determine Role Membership for the user (if the admin has configured ldap roles)
• Fetch any configured attributes (if the admin has configured ldap attributes)

These operations allows us to fully determine group/role membership which is critical for optimized authorization handling for the rest of the user’s session.

So two things you can remove are any ldap attributes config and any ldap role config. Although based on your comments you probably haven’t configured these anyway.

The next thing to do is to modify the group query. Are you using ldap groups? If not, then you could modify the LDAP Directory Service to point to an empty groups dn to ensure no results are returned.

At that point, you can enable Directory Debugging (using the Log Configuration portlet) to see each and every LDAP query executed as well as the execution times in the logs. This should give you the exact information to know:

• What ldap queries are executed
• How long each query is taking

If you’re still experiencing the times you mentioned, please contact Technical Support and we’ll examine other options.

Regards,
–mark

Hi Mark,

1. By LDAP attributes config are you referring to the attributes under User Attributes on the directory admin service screen?
2. Similarly, by group query is it the group object class and other attributes?

Thanks

1. You can modify the Ldap Principal Attribute provider to ‘provide’ or expose custom attributes from your ldap dir server. You probably haven’t done this, so don’t worry about it.
2. The Group query will take into account the object class and dn if provided.

I would highly recommend modifying the debug levels so that you can see precisely what ldap queries are occurring.

Regards,
–mark