56
WEBSPHERE PORTAL V6.1 TUNING GUIDE
Real-World Network Considerations
In our lab environment, we had the luxury of our clients and servers being 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 which can help alleviate this situation:
•
Compress content on the HTTP server
•
Allow client-side caching of images, Javascript files, and stylesheets,
Details on these steps will be given below.
C O M P R E S S C O N T E N T O N T H E H T T P S E R V E R
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...