Many login performance issues turn out to be delays in resolving group membership. WebSphere Portal attempts to resolve group membership at each login. There are a few things a Portal administrator can do to make the process of resolving group membership as efficient as possible. Reducing the load on the LDAP is a bonus.
1. If your LDAP supports it, implement a membership attribute. Set the scope as broadly as your LDAP supports. Hopefully, the LDAP's membership attribute lists all of a user's group memberships (direct, nested, and dynamic).
Note: Be sure that any groups returned by the membership attribute can be resolved within the realm defined in VMM. Failures will occur if the membership attribute returns a group DN that VMM cannot look up.
2. Unless your application requires them, avoid using dynamic groups since resolving their membership exacts a high cost. If you need dynamic groups in your application, consider keeping them locally with this alternative.
3. If the membership attribute resolves nested groups, disable nested groups in Portal.
4. Configure a federated repository so that VMM resolves group membership during the WAS login process. Then configure Portal to reuse WAS group information (user management only, to maximize performance).
Note: You can reuse WAS group information even in a standalone LDAP configuration - I just like the VMM functionality for resolving group membership better.
There are some additional tweaks you can make with PAC caches, VMM caches, and context pooling, but these four items should help a great deal in resolving any performance delays in resolving group membership during Portal login.