TOC PREV NEXT INDEX

Optimizing Server Memory Consumption


Making the best use of memory in a web application can depend on a variety of different factors and has to be balanced against the effects on performance. The ICEfaces framework has a number of different ways to influence memory usage, many of which can be configured to best suit the characteristics of your particular application.

State Saving

The choice of state saving implementation can have a dramatic impact on performance. Refer to State Saving, for more information


DOM Compression

One of the features of ICEfaces is Direct-to-DOM rendering, a strategy which uses a server-side copy of the client's DOM tree to generate the initial response as well as to compare and generate differences in order to calculate incremental page updates. While this has many advantages, the fact that the DOM remains in memory between requests has implications for memory usage. To that end, ICEfaces has an option to serialize and compress the DOM between requests. By default, this feature is turned off, but it can be activated by setting the following configuration parameter in your web.xml file: 

<context-param>
 
     <param-name>com.icesoft.faces.compressDOM</param-name>
 
     <param-value>true</param-value>
 
 </context-param>

The impact of the memory savings will depend on the nature of your application. If you have pages that comprise large DOMs, something typically found in applications that are designed towards a "single-view" architecture, then the savings are likely to be more significant. There is, of course, a small performance impact to compress and decompress the DOM.


Note: When specifying "com.icesoft.faces.compressDOM=true", the Fastinfoset.jar library (available in the /icefaces/libs/ directory) must be included in your project classpath.
String Handling

String handling and manipulation is a big part of JSF and ICEfaces. Therefore, it is important to consider the impact of creating String objects, particularly if the same strings are used repeatedly. For example, strings that are used for the various component attributes - JSF client IDs, CSS class names, expression language bindings, etc. - need to be dealt with efficiently so that they do not use more memory than is necessary while still remaining performant.

Given these constraints, ICEfaces makes use of bounded string pools based on the LRU (least recently used) algorithm to store values for commonly and repeatedly used strings. We currently provide 4 logically separate String pools, whose initial size is configurable through context parameters. These parameters are:

The default size for each pool is 95000. To change the default value for one or more of these parameters, you would add an entry to your web.xml file that looks like this: 

    <context-param>
 
        <param-name>com.icesoft.faces.clientIdPoolMaxSize</param-name>
 
        <param-value>50000</param-value>
 
    </context-param>

While the default size provides a good general fit for most applications, the optimal settings for your application will depend on the nature of your application. Applications will fewer, smaller, and simpler pages could benefit from a smaller pool size, whereas applications with larger or more complex pages may want to set the pool size higher.

Detailed reference information on these and other ICEfaces configuration parameters can be found in Appendix B: ICEfaces Configuration Parameter Overview.



Copyright 2005-2009. ICEsoft Technologies, Inc.
TOC PREV NEXT INDEX