Table of Contents
Advertisement
5.2.5 Web container
The Web container serves to "gate" the amount of incoming HTTP requests. The larger the
number of threads, the higher the number of concurrent requests are allowed to enter the
Web container. At some point, however, the number of concurrent threads being processed
by the Web container can overwhelm its abilities.
Display Caching should be explicitly enabled for the Portal Web container. In addition, if the
WebSphere Dynacache mechanism is going to be utilized by the Portal for Portlet fragment
caching, the enablement of Servlet Caching is a prerequisite.
To view or modify the Web container settings from the WebSphere Application Server
Administrative Console, select Servers → Application Servers → WebSphere_Portal →
Additional Properties → Thread Pools → Web Container. Table 5-5 shows the default and
recommended settings.
Table 5-5 Web container settings
Parameter
Enable Servlet Caching
In terms of Portal performance, an increase in the maximum number of threads can offer an
improvement. However, care should be taken, as increasing the value too high above the
suggested optimum value of 75 threads can lead to greater %CPU and memory usage.
Setting the number of minimum threads equal to the number of maximum threads does not
normally offer any immediate improvement after startup. An examination of a Java thread
dump will fail to show a thread count matching the minimum thread setting immediately after
initialization.
To view or modify the Web container settings from the WebSphere Application Server
Administrative Console, select Servers → Application Servers → WebSphere_Portal →
Additional Properties → Thread Pools → Web Container. Table 5-6 shows the default and
recommended values.
Table 5-6 Web container settings
Parameter
Minimum Threads
Maximum Threads
Is Growable
Under no circumstances should the "Allow thread allocation beyond maximum thread size"
feature be enabled. Permitting this setting can lead to runaway thread growth. The
WebSphere queuing mechanism is designed to handle burst traffic, and occasional "floods" of
the Web container should subsume relatively quickly in most circumstances.
Attention: Our experience tells us that one commonly made mistake is that many
customers increase the maximum thread pool setting beyond the recommended value in
the hope of increasing performance. As this runs the risk of overwhelming the ability of a
single JVM, our advice instead is to divide and conquer (D&C) by implementing
WebSphere clustering. Running many JVMs, or cluster members, each with a smaller Web
container, will prove beneficial when compared to a single JVM deployment with a large
Web container.
148
IBM WebSphere Portal V6 Self Help Guide
Default value
Disabled
Default value
10
50
Disabled
Recommended value
Enabled
Recommended value
55
75
Disabled
Advertisement
Table of Contents
Troubleshooting
