Managing the Retrieval of User Attributes
A user directory doesn’t just contain a user’s ID and password; it also contains a number of other pieces of information – attributes – about the user. A directory server can contain a lot of attributes for each user, so if every reference to a user required retrieving all of these attributes, this would impose a performance penalty on both the Portal server node(s) and the directory server node(s).
Therefore WebSphere Portal attempts to optimize the loading of these attributes. Two sets of user attributes are defined: the base set of attributes, and the minimum set of attributes. Depending on what action caused the user to be retrieved from the directory, either the base or the minimum set of attributes will be retrieved. Typically, the base set of attributes will be loaded when the user is retrieved; for example, this is what occurs when a user logs in. If the user was looked up when searching for users, then the minimum set of attributes will be loaded. For example, this can occur when searching for users to assign access to a page.
By default, WebSphere Portal defines the user attribute sets as follows:
∙Base set: the following attributes are in the base set: o uid
o cn o sn
o preferredLanguage o
o displayName
∙Minimum set:
ouid o cn
What happens if additional attributes are needed? For example, consider a portlet which requires the user attribute countryName. Assume that the user in question was looked up on login, so the base set of attributes was retrieved. The attribute countryName isn’t in the base set, so the full user record – with all of its attributes – will be retrieved from the directory server at that point. This will require a second request to the directory server. Also, since all user attributes are retrieved on the second request, this can end up consuming more memory on the WebSphere Portal server.
This provides an important performance tuning point to both improve response times and reduce load on the directory server. If a user attribute will commonly be needed, then it should be included in the base set of attributes so that it’s retrieved on the initial lookup, eliminating the need for a second request. However, if an attribute is only needed infrequently, consider leaving it out of the base set of attributes, so that it’s not retrieved for all users.
5 3
