IBM BS029ML - WebSphere Portal Server Self Help Manual page 141

If you suspect the page rendering is the bottleneck, try to eliminate the portlets on the page
one at a time to find the most time consuming ones, and move them to the secondary pages.
The design of the welcome page should be kept as simple as possible to avoid retrieving data
from any back-end systems. One common test is to create a blank page to put in place as the
login landing page, thus compare the login landing page with this blank page to discover
whether the portlet rendering is the bottleneck. If the portlets on the login landing page
require a proxy server to access the internet, forgetting to configure the proxy server may
result in a long delay, depending on the timeout of the proxy settings defined by the portlets.
Common causes of slow login
The following list is not meant to be exclusive and there are potentially many more problems
that can result in slow login. Sometimes an IP level trace is required to find the bottleneck:
Slow LDAP server, or database, or network, including faulty network interface card (NIC)
LDAP referrals
Firewall caused stale connections
Nested groups and large number of groups users belong to
Slow portlet rendering due to back-end systems
Portlet rendering or proxy access
Complicated permission settings
If the slow login only happens at the first login right after a server restart, using the "Warmup"
service may help. To enable AccessControlWarmupService, locate "WP
AccessControlWarmupService" from the WebSphere Application Server Administrative
console, and add a custom property with "enabled" as the name and "true" as the value.
You may also want to check the sizes of the Access Control caches, which can be found in
"WP CacheManagertService" in the admin console, and follow the suggestions provided in
the white paper, Performance Tuning of Portal Access Control, found at:
http://www.ibm.com/developerworks/websphere/library/techarticles/0508_buehler/0508
_buehler.html
Although this paper was written for WebSphere Portal Version 5, the principles are still
applicable to Version 6 as well.
Single sign-on (SSO) is not working
There are several major scenarios in which SSO fails to work.
When the problem is only with the portal security configuration itself, the observation is that
after you enter the user ID and password, you are not redirected to the next page; instead,
you stay on the same page as though nothing happened. When this happens, make sure that:
The single sign on domain in global security configuration is configured.
The fully qualified server host name is used when accessing the portal URL.
The browser is configured to accept cookies.
The system timers of the server and client are synchronized.
When the security of the portal server is configured to use an external security manager
(ESM) like Tivoli Access Manager, the observation of this problem is that the users have to
enter their credentials twice, one with the reverse proxy, and the other at the portal server. As
we have emphasized before, you should always make sure the base SSO configuration works
before moving on to configure ESM for authentication. You should also check the Trust
Chapter 4. WebSphere Portal security
127