Skip to main content link. Accesskey S
  • Help
  • IBM Logo
  • IBM Web Experience Factory wiki
  • All Wikis
  • All Forums
  • ANNOUNCEMENT: Wiki changed to read-only. READ MORE...
  • Home
  • Product Documentation
  • Community Articles
  • Learning Center
  • IBM Redbooks
  • API Documentation
Search
Community Articles > Web Experience Factory > Best Practices for Web Experience Factory > Performance Best Practices
  • Share Show Menu▼
  • Subscribe Show Menu▼

About the Original Author

Click to view profileRob Flynn
Contribution Summary:
  • Articles authored: 199
  • Articles edited: 253
  • Comments Posted: 2

Recent articles by this author

JAX-WS Handler Sample using IBM Web Experience Factory

Overview The Web Experience Factory (WEF) 8.0 release contains an enhancement to the web service call builders that gives you an option to define a global JAXWS handler class. This handler makes it possible for models to intercept and process the inbound and outbound SOAP envelopes ...

WebSphere Dashboard Framework 7.0.1.1 Fix pack now available

The WebSphere Dashboard Framework 7.0.1.1 Fix pack has been released.

IBM Web Experience Factory Version 7.0.1.4 Fix Pack is now available

This fix pack includes new fixes and updates for Web Experience Factory Version 7.0.1. and is now available on Fix Central and can be downloaded from here: ...

IBM Web Experience Factory WCAG 2.0 Compliance

IBM Web Experience Factory, developed and tested compliant to WCAG 2.0, can produce output ( web pages , sites and content) that can be WCAG 2.0 Level A and Level AA compliant. IBM Web Experience Factory neither enforces nor prevents this compliance. Application developers must know and understand ...

Yeah!!! New IBM Web Experience Factory V8.0 is announced!!!

A quick snapshot of what's new in IBM Web Experience Factory... IBM Web Experience Factory is all about making it quick and easy to develop applications (portlets) that are included as part of an exceptional web experience. We've seen our customers doing some awesome stuff, whether it be ...
Community articlePerformance Best Practices
Added by Rob Flynn | Edited by IBM contributorMike Burati on February 11, 2010 | Version 46
expanded Abstract
collapsed Abstract
No abstract provided.
Tags: Best practices, performance
ShowTable of Contents
HideTable of Contents
  • 1 Overview
    • 1.1 Avoid  retrieving large data sets and large session variables
    • 1.2 Transform results in stateless service providers not in service consumers
    • 1.3 Use caching across users when feasible
    • 1.4 Avoid deploying a large number of WebSphere Portlet Factory WAR files
    • 1.5 Restart Performance Test and Production Servers after redeploying WARs
    • 1.6 Use the latest version and fixpack of WebSphere Portlet Factory
    • 1.7 Use WebSphere Portlet Factory built in logging and diagnostic tools to look at performance related information
    • 1.8 Use automated load testing tools to validate the performance and capacity of your application
    • 1.9 See the WebSphere Portal and WebSphere Application Server tuning guides for recommendations to optimize server performance.
    • 1.10 Be aware of the impact of WebSphere Portlet Factory profiling features
    • 1.11 When using profiling for Personalize support in WebSphere Portal consider using the Execution Time setting for profile entries
    • 1.12 Utilize the capabilities of external systems when possible
    • 1.13 Disable testing support in service provider models
    • 1.14 Avoid excessive logging and related String construction

Overview

This page collects some best practices for Portlet Factory related to performance and memory. This is not a comprehensive list, and most of the best practices for the underlying platforms – WebSphere Portal, J2EE and WebSphere Application Server, and Java - are also applicable for Portlet Factory applications.
 

Avoid  retrieving large data sets and large session variables


 
Large data sets are the most common cause of memory capacity issues. Here are some suggestions for how to keep data sets smaller.

- When retrieving data, try to retrieve a small amount for viewing at a time. Depending on your data source, you can often reduce size with a more restricted query (to reduce the number of rows and/or number of columns retrieved). With SQL builders, you can use a selective query to do this. With Domino, you might consider using or creating more selective views in Domino, to reduce the row and column count.
If you can't restrict the data set size from the data source (for example, if you only need to display a few columns while your data source returns a lot of columns), you can create a service provider that removes unneeded data, so that the data used by your consumer model (and potentially stored in session) is smaller.

- If you have a large set of categorized data, consider providing an interface that initially shows just a list of the categories, with links to retrieve data for a single category at a time. This technique uses much less memory than retrieving the entire data set and displaying it with Category Row builder, for ex ample.

- Caching of results can be another technique for sharing data across users and reducing session memory use. For example, if you enable caching in the Service Operation builder, all users (for the same profile) will share the same result object. This sharing will occur even though the result variable may be session-scoped in the consumer model - each user session will have a reference to the same Java object.

- Use paging to fetch data in subsets. There are a number of builders in Portlet Factory that support a UI for paging through tabular data sets. For example, there are paging options in the View & Form builder and the Data Page builder, and the Paging Assistant builder provides some of the underlying support. These paging features can use a "DataRetriever" interface that can be used to automatically fetch data in chunks from an external source. Some data access builders such as SQL Call and Domino Data Access can provide support for a paging DataRetriever interface. Other data access builders such as SAP Function Call do not have any built-in support for paged data access. There are two samples that show some custom support for paging data: IBM - Paged web service provider and IBM - Creating a custom data paging provider. When you are using Data Page builder to display paged data, be sure to select the top-level variable as the data to display, not an XML element within the variable.

- For large variables, if they can be marked as "Shared (read-only)", they will share a copy instead of having a copy in each session. Some builders such as Localized Resource will create read-only variables. Similarly, Variables that are marked as request scoped will not be stored in the session.

- In Portlet Factory 6.1, you can use the Discardable Variable builder to convert a variable to request scope, with support for reloading data if needed and for caching in WebSphere DynaCache.

Note that in Portal, each portlet gets its own session, and once a portlet session is created, it is not released until the entire Portal session is released. This means that if you have a large number of portlets spread across many Portal pages, they can potentially all end up in session. Therefore when you have a large number of portlets, it's especially critical to keep Variables in session as small as possible.

Transform results in stateless service providers not in service consumers


Many use case scenarios call for creating simpler UI-oriented schema defined structures and transforming larger complex result sets from back end integration calls into these smaller structures. When calling these back end data integration operations via stateless service provider, it is significantly more efficient to transform the results into the new variable structure in the stateless service provider than it would be to do so in the consumer. By not exposing the larger result set outside of the stateless provider, you end up only storing the smaller transformed variable in the user's session in the consumer. If you instead return the entire result set to the consumer and transform it there, you would be storing both the original larger results that you no longer need and the transformed results in each user's session, thus using a lot more memory under a heavy user load on the system.

Use caching across users when feasible


The Cache Control builder lets you cache the results of an operation across users. The results are shared for all users of the same model and profile, so this m echanism is not suitable for user-specific queries or results.
The Service Operation and Lookup Table builders also have options for caching results, and both use the functionality of the Cache Control builder under the covers.
Note that when you are using the Cache Control builder, you have to select a method that returns the data to cache, and that method should not have any important side effects.
If you cache a method or service operation that takes input arguments, the Cache Control builder will automatically keep a separate cache entry for each unique set of input values. Therefore you should use it cautiously for methods that take arguments, since you could potentially end up with a large number of cache entries.
The data cached with these builders is associated with a specific generated WebApp. In other words, each profile will in general have its own cache. This is necessary in some cases. However, if you have a scenario where data can be cached across profiles, it may be best to implement the caching in a non-profiled model (perhaps a service provider model), so that the cached data can be shared across all users.

Avoid deploying a large number of WebSphere Portlet Factory WAR files


Instead, combine portlets in a small number of WAR files (ideally, one or two). You can have as many portlets as you want in a single WAR file. Each WAR has overhead of 8MB or more, so if you deploy 20 WARs, you could use perhaps 150MB - 200MB extra memory, when compared with using a single WAR. Also, keep in mind that Portlet Factory caching cannot be shared across WARs. For example, if you have a service provider with a cached operation returning several MB of data, each WAR will have its own copy of that data.

Restart Performance Test and Production Servers after redeploying WARs


When you redeploy a WAR, the server stops the application, replaces the deployed WAR with the new one, and thus when it starts up you have a NEW copy of all the WAR's necessary classes loaded into memory. JVMs don't immediately garbage collect "classes" (as opposed to object instances), and some classes may have static references to the old (pre-redeployment) caches, which can then keep references to old cache data object instances in memory. To avoid unnecessary memory use by those old classes, it is a best practice to restart performance test servers and production servers after redeploying your portlet WARs, to immediately remove any old classes from memory.

Use the latest version and fixpack of WebSphere Portlet Factory


Each Portlet Factory release typically includes additional performance and memory optimization work. By using the latest release you can get the benefit of all Portlet Factory product improvements related to performance. Check to make sure you have the latest fixpack also.

Use WebSphere Portlet Factory built in logging and diagnostic tools to look at performance related information


There are some useful logging tools built into Portlet Factory that can help look at performance. For example:
- Server stats. Server statistics are recorded in a log file in deployed WAR files whenever the server is running. The server stats logging records statistics about requests to the Portlet Factory application every five minutes. This can provide valuable information about the "health" and performance of the application, and is most useful for looking at servers under load, either in testing or production. Since server stats logging does not add any significant performance overhead, it is recommended that they are left enabled (as they are by default). The server statistics are written to WEB-INF/logs/serverStats.txt.
- Model action tracing. This feature lets you see all the actions that take place during server requests to a model. It shows the sequence of operations, such as calls to methods and page display, with elapsed time for each. This is most useful for looking at application behavior for a single user during testing.
- Session size diagnostics. This feature lets you see all the variables that are in use by a running application. It can help you find areas where you may be putting a lot of data into session, for example, by retrieving a large data set. Like model action tracing, this is most useful for targeted testing with a single user.
This tech note has more information on these features: Techniques to enhance WebSphere Portlet Factory application peformance

For analyzing overall Java heap memory use, the verbose GC logging should be enabled in the application server. This log file (native_stderr.log) can be conveniently viewed with the PMAT tool available on developerWorks (http://www.alphaworks.ibm.com/tech/pmat).
These slides describe some of the performance analysis tools that are used with Portlet Factory: Portlet Factory Performance Analysis Tools.

Use automated load testing tools to validate the performance and capacity of your application


In order to find the capacity for a particular application, for example to know how many concurrent users can be accomodated on a single server, there is no substitute for automated load testing of the application. Every application is different, and it is often not possible to extrapolate between applications.

See the WebSphere Portal and WebSphere Application Server tuning guides for recommendations to optimize server performance.


For WebSphere Portal, see the IBM WebSphere Portal Version 6.0 Tuning Guide

Be aware of the impact of WebSphere Portlet Factory profiling features


When you use profiling, each u nique profile will generate its own "WebApp" object in memory, with metadata describing the pages, methods, variables, and so forth for the model. Each WebApp also has separate cached results when you use the Cache Control builder or the caching features of Service Operation and Lookup Table. Therefore you should avoid having a very large number of different profiles for a model. For example, if you allow individual users to edit profile values with the "Edit" mode in Portal, you might potentially end up with a separate WebApp for every user. See the next item for how to avoid this.
Also, when you are using caching, if you can cache data in an unprofiled model such as a service provider model, this is better than caching data in a profiled model, since you'll have a single shared cache instead of multiple entries. On the other hand, if you need profile-specific cache results, you can get them by caching in the profiled model

When using profiling for Personalize support in WebSphere Portal consider using the Execution Time setting for profile entries


When you allow users to edit individual values in "Edit" mode, you may have a potential situation where each user ends up with their own generated WebApp (see information above on the impact of profiling). The "Execution Time" setting for profile entries can, in some scenarios, allow you to avoid this, by having the developer indicate which profile values are simple runtime values that don't require a unique regen. This technique can also be valuable in other situations (in addition to Edit mode) where you may have a large number of unique profiles.
To edit this setting, open up the profile set by double-clicking the ".pset" file, then go to the "Entries" tab, select the desired profile entry and click the "Edit" button. The choice for Execution Time is at the bottom of that dialog box. Note that you can only use this choice when the associated profiled builder input can accept a runtime value such as a variable reference. It cannot be used when profiling a value which would result in different generated code, such as the filename for the Imported Page builder.

Utilize the capabilities of external systems when possible


Instead of using a Method / LJO to categorize, sort, compute, or sum data from an external source, let the external data storage system to do the work for you. Usually sources such as databases are much better equipped to handle such tasks.

Disable testing support in service provider models


Before deploying, you should disable service testing by unchecking the "Add Testing Support" in the Service Definition builder (or disabling the Service Test builder if you are using that). The generation of service test pages uses some additional memory when models are generated.

Avoid excessive logging and related String construction


Logging code that generates a lot of output should be disabled in production and load testing, and only enabled selectively if needed. In all logging code, the code should first test to see if logging is enabled before constructing String objects for log output, since the String construction itself can use a lot of temporary memory.
expanded Attachments (0)
collapsed Attachments (0)
expanded Versions (76)
collapsed Versions (76)
Version Comparison     
VersionDateChanged by              Summary of changes
76Aug 7, 2012, 8:39:39 AMJonathan Booth  IBM contributor
75Mar 1, 2012, 11:44:24 AMMichael Burati  IBM contributor
74Feb 12, 2010, 3:28:54 PMMike Burati  IBM contributor
73Feb 12, 2010, 3:19:10 PMMike Burati  IBM contributor
72Feb 12, 2010, 3:17:48 PMMike Burati  IBM contributor
71Feb 12, 2010, 3:13:26 PMMike Burati  IBM contributor
70Feb 12, 2010, 3:07:16 PMMike Burati  IBM contributor
69Feb 12, 2010, 3:05:58 PMMike Burati  IBM contributor
68Feb 11, 2010, 4:15:05 PMAmanda J Bauman  IBM contributor
65Feb 11, 2010, 4:10:26 PMRob Flynn  IBM contributor
64Feb 11, 2010, 4:10:02 PMRob Flynn  IBM contributor
63Feb 11, 2010, 4:09:17 PMRob Flynn  IBM contributor
62Feb 11, 2010, 4:08:52 PMRob Flynn  IBM contributor
61Feb 11, 2010, 4:08:32 PMRob Flynn  IBM contributor
60Feb 11, 2010, 4:08:08 PMRob Flynn  IBM contributor
59Feb 11, 2010, 4:07:32 PMRob Flynn  IBM contributor
58Feb 11, 2010, 4:06:13 PMRob Flynn  IBM contributor
57Feb 11, 2010, 4:05:25 PMRob Flynn  IBM contributor
56Feb 11, 2010, 4:04:45 PMRob Flynn  IBM contributor
54Feb 11, 2010, 4:03:32 PMRob Flynn  IBM contributor
53Feb 11, 2010, 4:02:23 PMRob Flynn  IBM contributor
53Feb 11, 2010, 4:00:19 PMRob Flynn  IBM contributor
52Feb 11, 2010, 3:54:17 PMRob Flynn  IBM contributor
51Feb 11, 2010, 3:58:09 PMR Flynn  IBM contributor
51Feb 11, 2010, 3:53:01 PMRob Flynn  IBM contributor
50Feb 11, 2010, 3:52:26 PMRob Flynn  IBM contributor
50Feb 11, 2010, 3:52:26 PMRob Flynn  IBM contributor
47Feb 11, 2010, 3:43:33 PMMike Burati  IBM contributor
47Feb 11, 2010, 3:51:04 PMRob Flynn  IBM contributor
46Feb 11, 2010, 3:42:03 PMMike Burati  IBM contributor
This version (46)Feb 11, 2010, 3:42:03 PMMike Burati  IBM contributor
45Feb 11, 2010, 3:40:18 PMMike Burati  IBM contributor
44Feb 11, 2010, 3:37:55 PMMike Burati  IBM contributor
43Feb 11, 2010, 3:36:17 PMMike Burati  IBM contributor
42Feb 11, 2010, 3:35:26 PMMike Burati  IBM contributor
41Feb 11, 2010, 3:34:49 PMMike Burati  IBM contributor
40Feb 11, 2010, 3:31:07 PMMike Burati  IBM contributor
39Feb 11, 2010, 3:16:06 PMMike Burati  IBM contributor
38Feb 11, 2010, 2:29:51 PMMike Burati  IBM contributor
37Jan 4, 2010, 10:46:34 AMRob Flynn  IBM contributor
36Jan 4, 2010, 10:45:20 AMRob Flynn  IBM contributor
35Jan 4, 2010, 10:40:48 AMRob Flynn  IBM contributor
34Nov 28, 2009, 8:29:14 AMJonathan Booth  IBM contributor
33Oct 2, 2009, 2:41:35 PMMike Burati  IBM contributor
32Jun 22, 2009, 3:37:20 PMJonathan Booth  IBM contributor
31Apr 2, 2009, 4:29:16 PMMike Burati  IBM contributor
30Apr 2, 2009, 2:45:42 PMMike Burati  IBM contributor
29Apr 2, 2009, 2:43:05 PMMike Burati  IBM contributor
28Apr 2, 2009, 2:39:37 PMMike Burati  IBM contributor
27Apr 2, 2009, 2:28:37 PMMike Burati  IBM contributor
26Apr 2, 2009, 2:26:12 PMMike Burati  IBM contributor
25Apr 2, 2009, 2:01:07 PMMike Burati  IBM contributor
24Apr 2, 2009, 1:59:48 PMMike Burati  IBM contributor
23Apr 2, 2009, 1:40:58 PMMike Burati  IBM contributor
22Apr 2, 2009, 9:00:37 AMMike Burati  IBM contributor
21Dec 16, 2008, 11:26:43 AMJonathan Booth  IBM contributor
20Nov 26, 2008, 4:08:06 PMJonathan Booth  IBM contributor
19Nov 2, 2008, 10:44:10 AMJonathan Booth  IBM contributor
18Nov 2, 2008, 10:42:39 AMJonathan Booth  IBM contributor
17Oct 7, 2008, 1:03:29 PMDeAnna Steiner  IBM contributor
16Oct 7, 2008, 1:03:04 PMDeAnna Steiner  IBM contributor
15Aug 6, 2008, 3:22:55 PMJonathan Booth  IBM contributor
14Aug 6, 2008, 3:20:28 PMJonathan Booth  IBM contributor
13Aug 6, 2008, 3:19:15 PMJonathan Booth  IBM contributor
12Aug 6, 2008, 3:18:20 PMJonathan Booth  IBM contributor
11Aug 6, 2008, 3:17:38 PMJonathan Booth  IBM contributor
10Jul 16, 2008, 11:55:20 AMJonathan Booth  IBM contributor
9Jul 16, 2008, 11:52:14 AMJonathan Booth  IBM contributor
8Jun 24, 2008, 2:23:28 PMRob Flynn  IBM contributor
7Jun 24, 2008, 2:19:05 PMRob Flynn  IBM contributor
6Jun 13, 2008, 1:01:44 PMRob Flynn  IBM contributor
5Jun 12, 2008, 4:01:59 PMRob Flynn  IBM contributor
4Jun 4, 2008, 2:49:05 PMRob Flynn  IBM contributor
3Jun 2, 2008, 3:45:04 PMRob Flynn  IBM contributor
2Jun 2, 2008, 2:50:34 PMRob Flynn  IBM contributor
1May 22, 2008, 2:24:05 PMRob Flynn  IBM contributor
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedHelpAbout
  • IBM Collaboration Solutions wikis
  • IBM developerWorks
  • IBM Software support
  • Twitter LinkIBMSocialBizUX on Twitter
  • BlogsIBMSocialBizUX on Facebook
  • ForumsLotus product forums
  • BlogsIBM Social Business UX blog
  • Community LinkThe Social Lounge
  • Wiki Help
  • Forgot user name/password
  • Wiki design feedback
  • Content feedback
  • About the wiki
  • About IBM
  • Privacy
  • Accessibility
  • IBM Terms of use
  • Wiki terms of use