In addition to the scenarios discussed above, IBM® WebSphere®
Portal has some other tuning options which may be useful in specific scenarios.
These options include:
Contents
Improving Portal Startup Performance
Managing the Retrieval of User Attributes
Identifying a Full Fetch of User
Attributes
Minimum Attribute Set
Use of Dynamic Content Features
Real-World Network Considerations
Compress Content on the HTTP
Server
Enabling Client-Side
Caching
WebSphere Portal 6.1 introduced a development mode that greatly
improves startup performance, so that WebSphere Portal will start more quickly.
This can be very useful for development environments where WebSphere Portal
must be stopped and started frequently.
However, it is important to
note that this mode is only meant to be used for development or test
environments, not production or performance benchmark environments. Development
mode turns on lazy-start for almost all applications in WebSphere Portal, and
this can cause a performance impact the first time an application is accessed
under load. Development mode also changes the way the JVM is started to give
better startup speed at the cost of reducing capacity under load.
To
switch to development mode, run the enable-develop-mode-startup-performance
configuration task to complete the configuration and optimize the portal
startup. The changes can be reverted to the original values using the
disable-develop-mode-startup-performance configuration task.
For
more information, refer to the following topic in the WebSphere Portal
Information Center:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.w
p.ent.doc/install/inst_opt.html
A user directory does not contain only a user’s ID and password; it
also contains several other pieces of information, or attributes, about users.
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).
For this reason, 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:
uidcnsnpreferredLanguageibm-primaryEmailgivenNamedisplayName
- Minimum set:
However, there are some situations when 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 is not 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.
IDENTIFYING A FULL FETCH OF USER ATTRIBUTES
How can you identify a second request is made to the directory server
to retrieve the full set of user attributes? This is best done in a test or
staging environment, rather than a live production environment, as it requires
turning on tracing in the portal server, and this can impose a significant
performance overhead. There are two traces to enable to look for this
condition. The first one will show if the all the needed user attributes have
been retrieved. If this is false, then a full fetch of the user information
will occur. The second trace shows which attributes are being requested, so you
can tell which ones should be added to the base set.
The trace strings are as follows:
com.ibm.wps.um.PrincipalImpl=all=enabled
com.ibm.wps.um.PumaProfileImpl=all=enabled
Enable the preceding two traces, then run the use case you want to test.
After running the use case, look for this message in trace.log:
PrincipalImpl 3 com.ibm.wps.um.PrincipalImpl isCompletelyLoaded
false
This message may be output multiple times for the same
user, so check all occurrences of it. If the value after
isCompletelyLoaded is always true, then all the
needed attributes have already been loaded, and no changes are needed. In this
example, the value after isCompletelyLoaded is false,
showing that not all the required user attributes have been loaded. This will
result in reloading all the user information from the user directory.
In that case, the trace will then typically show a call to reload the
information for that user; this will tell the full distinguished name of the
user whose information is being loaded from the user directory:
PrincipalImpl > com.ibm.wps.um.PrincipalImpl reload ENTRY id: cn=Yin
Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
Next, search above that in the trace for the getAttributes call, which will
show the attributes the user has requested. It will look like this:
PumaProfileIm > com.ibm.wps.um.PumaProfileImpl getAttributes ENTRY id: cn=Yin
Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com
…more user details follow…
isExternal: false[preferredLanguage, ibm-primaryEmail, countryName,
displayName, givenName, cn, sn, uid]
The last line of the log entry shows the attributes being requested. In this
case, the attributes being requested are [preferredLanguage,
ibm-primaryEmail, countryName, displayName, givenName, cn, sn, uid].
Comparing this to the list of base user attributes, we can see that
countryName is not in the base user attributes. Depending on
whether the action being run is a common one or not, consider adding this
attribute to the base set of attributes.
MINIMUM ATTRIBUTE SET
Generally, the minimum set of attributes does not need to be modified
from the default provided by WebSphere Portal, as that attribute set is
satisfactory for the user management applications provided with WebSphere
Portal. However, if your site contains a custom application for managing users
and groups, and it uses attributes other than those in the minimum set, then
you should consider expanding the minimum attribute set.
WebSphere Portal contains dynamic content support infrastructure which
supports two dynamic content features: dynamic user interfaces and attribute
based administration. If neither of these features is being used, the dynamic
content support can be disabled. Note that attribute based administration is
only one use of the Personalization capabilities in WebSphere Portal; other
uses of Personalization, such as placing content spots within a portlet, do not
require the dynamic content features.
Disabling the dynamic content features will provide a modest performance
benefit. It will provide a reduction in the memory needed for each user, and
also reduce the processing time for generating pages in WebSphere Portal. For
example, in one measurement with our Base Portal scenario, capacity improved
about 5% when disabling the dynamic content support.
Disabling dynamic content support is done by adding a custom property to the
ConfigService.properties resource provider. The property is:
content.topology.dynamic=false
Refer to the Overview of configuration services topic in the
WebSphere Portal Information Center for more information on updating
configuration properties.
In our lab environment, we had the benefit of having our clients and
servers on the same LAN segment, so that they could take advantage of a
high-bandwidth, low-latency network connection. However, this is typically not
the case for real clients. Over a wide-area network, latencies can be
significant, and bandwidth limited. In this case, the time to transfer the page
content from the server to the client can become a significant contributor to
overall page response time.
Here are some steps that can help this situation:
- Compress content on the HTTP server.
- Allow client-side caching of images, JavaScript files, and
stylesheets.
Details on the preceding steps are as follows:
COMPRESS CONTENT ON THE HTTP SERVER
Much of the content served by a WebSphere Portal site can be
compressed to reduce transmission time and save network bandwidth. Typically,
images should not be compressed (as they are usually stored in a compressed
format), but other types of content can show a significant size reduction from
compression.
IBM HTTP Server supports Deflate compression through the
mod_deflate module. When it is enabled, the HTTP server checks the
Accept-Encoding: header sent by the browser to see if it can
accept a compressed version of the content. If so, the HTTP server will
compress the content before sending it to the browser.
In one measurement, we observed an average of 65% network traffic reduction
when Deflate compression is enabled. However, the compression operation does
not come free as we also observed approximately a 10% processor utilization
increase on the HTTP server.
To enable deflate compression in IBM HTTP Server, add the following lines in
httpd.conf:
# compress everything but images
LoadModule deflate_module modules/mod_deflate.so
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary
ENABLING CLIENT-SIDE CACHING
The HTTP protocol allows the server to tell clients how long they can
cache responses. When the client has the content in their cache, they do not
need to request it again, saving the round-trip time to the server to retrieve
the content.
This is done by adding Cache-Control: headers to the content which we wish to
make cacheable. By default, WebSphere Portal will include these headers in the
stylesheets it uses, making that content cacheable at a client for 5 days
(432,000 seconds). It is possible to use mod_headers in IBM HTTP
Server to add the same headers to images and JavaScript files by adding the
following lines to httpd.conf:
LoadModule headers_module modules/mod_headers.so
<Location ~ "\.(js|gif|jpg|jpeg|png)$">
Header add Cache-Control "public,
max-age=432000, post-check=172000"
</Location>
In addition to the scenarios discussed above, IBM® WebSphere® Portal has some other tuning options which may be useful in specific scenarios.