Tuning the Web 2.0 Theme (Tuning Guide 6.1.x) 

In the Web 2.0 theme environment a reverse proxy was used to cache content outboard of IBM® WebSphere® Portal. The reverse proxy was set up to take advantage of the fact that portlet fragments are fetchable and cacheable. This avoids having to refetch the entire portal page in many cases. This allowed some content to be fetched without going to the Web server or the Portal server. Performance can be further improved by having the reverse proxy configured to compress much of the content.
In general, the same tuning that was used for the Base Portal Scenario described in previous section was used for the Web 2.0 Scenario. The differences in tuning are described in the following sections.

Contents

     JVM Initial and Maximum Heap Size
     Navigator Service Properties
     Internet Explorer Support of Vary Header
     Caching Proxy Tuning
     Web Server Tuning
     Portlet Caching

JVM Initial and Maximum Heap Size

The Java™ Virtual Machine (JVM) Initial and Maximum heap size (ms and mx) were set to 1280. With higher values the system ran out of native memory under high virtual user load. You can resolve this problem by using the – Xalwaysclassgc JVM parameter along with setting -Xmx=1408. However the throughput was better with -Xmx=1280 than when using – Xalwaysclassgc and – Xmx=1408.

Navigator Service Properties

The following values were specified in NavigatorService.properties in addition to the parameters changed in the Base Portal tuning:

Table 16: Navigation Service Settings for Web 2.0 Theme

Parameter	Setting Used
remote.cache.expiration.feed.cm	600
remote.cache.expiration.feed.nm	600
remote.cache.expiration.feed.lm	600
remote.cache.expiration.feed.pm	600

Internet Explorer Support of Vary Header

When Microsoft® Internet Explorer 7 is sent a vary HTTP header, the browser is unable to cache that reply effectively. To configure WebSphere Portal to not send the vary header to Internet Explorer 7, do the following:

1. Log in to WebSphere Portal as an administrator.
2. Navigate to Administration > Portal Settings > Supported Clients.
3. Select .*MSIE 7.0.* (Internet Explorer 7) and click Edit selected client.
4. In the Capabilities field, select CACHE_VARY and click Delete then OK.

Repeat steps: Repeat the preceding steps for other versions of Internet Explorer as appropriate.

Caching Proxy Tuning

The following are the settings and tunings specified in the reverse proxy ibmproxy.conf file for the Web 2.0 performance test:

Table 17: Reverse Proxy Settings

Parameter	Setting Used	Additional Information
Proxy /wps/* http://server_name/wps/*		Proxy for /wps
Proxy /wps_semanticTag* http://server_name/wps_semanticTag* :80		Proxy for /wps_semanticTag
Proxy /searchfeed* http://server_name/searchfeed* :80		Proxy for /searchfeed
ConnThreads	15
ServerConnPool	on
MaxSocketPerServer	20
CacheTimeMargin	5 seconds
CacheFileSizeLimit	2 M
flexibleSocks	off
LimitRequestFieldSize	16384
CompressionFilterEnable	C:\PROGRA~1\IBM\edge\cp\Bin\mod_z.dll
CompressionFilter AddContentType	Image/bitmap,text/css,text/xml,application/xml	Compresses everything except text/html, application/atom+xml, text/plain, application/x-javascript. WebSphere Portal compresses those types. Experiments were done where reverse proxy compressed those files as well, which caused the reverse proxy CPU to become a bottleneck. If a more powerful reverse proxy server was available, it might make sense to do all gzipping on the reverse proxy. Note that fixes for PMR 43866,499 were applied to Edge Server v6.02 to get proper gzipping behavior.

Web Server Tuning

HTTP server tuning for cacheability:

# uncommented these to enable statics to be cached
    LoadModule expires_module modules/mod_expires.so
    LoadModule headers_module modules/mod_headers.so

# from http://www.contentwithstyle.co.uk/blog/147 avoid gzip bug in IE 6
    BrowserMatch ^Mozilla/4\.[0678] no-gzip
    BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html

# added this for caching of dojo javascript and the theme’s xsl files, max-age = 1 day
    <Location /wps/themes/dojo>
    Header set Cache-Control public;max-age=86400
    </Location>
    <Location /wps/themes/html/PortalWeb2/xsl>
    Header set Cache-Control public;max-age=86400
    </Location>
# info for these directives at http://httpd.apache.org/docs/2.0/mod/mod_expires.html
# http://httpd.apache.org/docs/2.0/mod/mod_headers.html

# set cache-control public for various static content
    <FilesMatch "\.(gif|jpeg|jpg|png|ico|css|js|swf)$">
    Header set cache-control "public"
    </FilesMatch>

# expire images after a month in the client's cache. Note that one month expiration worked fine for a performance evaluation in a test lab. It should be set appropriately for your environment where images might be updated more frequently than once a month.
    ExpiresActive On
    ExpiresByType image/gif A2592000
    ExpiresByType image/jpg A2592000
    ExpiresByType image/jpeg A2592000
    ExpiresByType image/png A2592000
    ExpiresByType application/x-javascript "access plus 1 week"
    ExpiresByType text/javascript "access plus 1 week"
    ExpiresByType text/css "access plus 1 week"
    ExpiresByType application/xml "access plus 1 week"
    ExpiresByType application/vnd.mozilla.xul+xml "access plus 1 week"
    ExpiresByType application/x-www-form-urlencoded "access plus 1 week"
    ExpiresByType text/html "access plus 1 week"
    ExpiresByType text/xml "access plus 1 week"

Portlet Caching

Web Archive (WAR) files contain the following portlet descriptor: portlet.xml. This XML file is located in the WEB-INF directory of the portlet WAR file. To make portlet fragments publicly cacheable, enter the following tags and parameters to portlet.xml between the <portlet> elements:

• <expiration-cache>28800</expiration-cache>
• <cache-scope>public</cache-scope>

In the Web 2.0 theme environment a reverse proxy was used to cache content outboard of IBM&#174; WebSphere&#174; Portal. The reverse proxy was set up to take advantage of the fact that portlet fragments are fetchable and cacheable. This avoids having to refetch the entire portal page in many cases. This allowed some content to be fetched without going to the Web server or the Portal server. Performance can be further improved by having the reverse proxy configured to compress much of the content.