ShowTable of Contents
End user, or client, performance is just as important to a WebSphere Portal site as server side performance. This article provides a checklist of items to verify that WebSphere Portal is functioning optimally on the client side.
Since these items deal with HTTP traffic, you will need development tools that can examine HTTP requests and responses after a Portal page is loaded in a web browser. Most browsers include development tools that can be used for basic analysis. However, other tools such as Fiddler, Firebug, HTTPWatch, Wireshark or Rational Performance Tester may provide more detail.
Details on fixing the issues listed here can be found in the WebSphere Portal Tuning Guide.
Check response headers for images and theme resources to make sure they include Cache-Control: public, max-age=. Note that any no-cache or no-store parameter will override other settings and cause that item to not be cached. For images and other static content the HTTP server needs to be configured to add those headers; see the Portal Tuning Guide section “Adding Cache Headers in IHS”.
For theme resources (ra:collection URLs), Portal will add those headers itself. If headers are not being set or have the wrong max-age, it could be due to the configuration of one or more modules in the theme profile. For information on diagnosing these issues, see https://developer.ibm.com/digexp/docs/docs/customization-administration/debugging-cachability-issues-theme-resource-aggregator-requests/.
Also consider adding Cache-Control: private, max-age= headers to content that is specific to a single user but could still benefit from caching in the browser. This content could include Portal pages that contain user specific content but does not change frequently.
See http://www-10.lotus.com/ldd/portalwiki.nsf/dx/TECH-B10__Caching_Techniques_for_WebSphere_Portal_and_Web_Content_Manager and http://www.ibm.com/developerworks/websphere/techjournal/0506_liesche/0506_liesche.html for more information on page & portlet caching.
It is also possible to GZIP Portal pages and other text content (HTML, XML & JSON) as well. This can reduce the bandwidth requirements for larger portal pages, at the expense of CPU utilization on the HTTP server. The more pages there are the more resources will be needed. In most cases the tradeoff will be worth it in terms of response time improvement for the end user.
Note that firewalls, load balancers and other security servers (e.g. WebSeal) may uncompress content in order to inspect HTTP traffic. When this is required, compression on the HTTP server will waste CPU resources. Instead, consider enabling compression on another network component.
See the Portal Tuning Guide sections "Content Compression on the HTTP Server".
portal vs myportal & contenthandler vs mycontenthandler URLs
By default, Portal serves resources with myportal or mycontenthandler URLs after login. However, the underlying theme resources will be the same if the authenticated and unauthenticated home pages use the same theme profile. By changing a security setting, Portal can reuse the non-authenticated contenthandler URLs after login. This will prevent the browser from re-downloading the same content and speed up the first page load after login. See the Portal Tuning Guide section "Avoid Refetching Static Content After Login".
ra:collection URL Request Counts
After accessing the base portal page, are any ra:collection URLs fetched? If so you might inadvertently be using different theme profiles on different pages. In general, it is best for performance if all pages use the same theme profile. This ensures that all theme modules are fetched on the landing page, cached by the browser, and never fetched again.
Image Request Counts & Sizes
Does a single page view require more than 10 images? If so, consider using sprites to group images into one file that is fetched with one HTTP request.
Are you fetching large images? Large images use more bandwidth and will take longer to load. Consider reducing the size of large images by making them smaller or saving them in a different format. For example, lowering the ‘quality’ setting on a JPEG photograph may reduce the file size without much loss of actual image quality. Saving images as PNGs instead of GIFs may also reduce file sizes.
Real Network Conditions
After tuning the site, have you measured performance on a WAN? A final measurement using realistic network bandwidth and latency are a good way to confirm your tuning and determine the actual performance an end user would see. Slower networks can also be simulated using Linux networking tools (qdisc) or with hardware appliances.
Also consider what hardware your end users will be running. CPU speed can affect browser processing time. Users may be using older or slower hardware (or mobile devices) so measurements should be run on similar systems.
Are any redirects happening (HTTP 302 responses)? In a properly functioning portal site, there should not be any redirects occurring for normal page views. If redirects are seen, they could be caused by a recommended tuning not being applied.
This could be caused by missing tuning or it could be caused by URLs being specified incorrectly. See the Portal Tuning Guide section "Reducing Redirects" for tuning that can eliminate redirects.
HTTP Not Founds
Reverse Proxy Configuration
If using a reverse proxy to cache, make sure ra:collection URLs are cached on the reverse proxy in GZIPped format and served to the back to the browser GZIPped as well.
Also ensure that the proxy is not sending Vary HTTP headers to Internet Explorer (IE). IE will continue to make HTTP requests for pages with Vary headers regardless of Cache-Control settings. See the Portal Tuning Guide section "Internet Explorer & Vary Headers".
Are any HTTP responses returning Connection: close headers? These headers will force the browser to close the HTTP connection and defeat any keepalive settings configured on your HTTP servers. Creating a connection takes at least 2 round trips to the server so avoiding the creation of new connections will speed up overall response time.
Use the YSlow tool (http://yslow.org/) to point out other page performance considerations.
About the Authors
Hunter Presnall is the WebSphere Portal Performance team lead. He has over 15 years of performance testing and analysis experience. He has been with IBM Lotus for five years and has previously worked on IBM Connections and IBM SmartCloud.
Andrew P. Citron is a performance engineer on the WebSphere Portal Performance team in IBM's Research Triangle Park. He is responsible for all Portal benchmarks on Windows and contributes to the WebSphere Portal tuning guides for each Portal release.