This, that and the other (may contain nuts)

Steve Castledine

XPages Memory Usage and Performance Tips - 8.5

Steve Castledine  9 July 2009 10:00:00
This maybe a two part post, but just before I went on holiday we did some analysis/work on a few XPage apps to improve performance and memory consumption. So heres a few tips that will help your applications. I have to state it is not official IBM documentation or guidelines, just my own based on discussions/working with some really clever people. I cannot be held responsible and all that jazz.

JVM Memory
The amount of JVM memory used by XPages is stored in the server ini parameter HTTPJVMMaxHeapSize. The default is 256M and I would recommend that to be set to 512 in order to support a higher number of concurrent users. Obviously if the resource is available, set it higher although 32bit systems have limits so 512 is probably the way to go.

64 bit systems obviously can support a higher value here as they are not restrained by the overall 2GB memory limit (windows).

JavaScript Variables
This is more important then you may realise and its not something I was aware of until we did some profiling, but any variables you declare within your XPages code do not automatically get cleared from the heap after use as they persist for the life cycle of the XPage (which is beyond just serving the page to the browser).

So whilst its always good practice to recycle early anyway, remember to clear variables especially large objects or strings that could remain in the server memory. From 8.51 there is a new property which can be set to clear all variables as soon as the code has run. As with anything mentioned for future releases its not guaranteed to actually be delivered etc etc.

If you need to store variables that do persist from page to page use the sessionScope or viewScope depending on your requirements. (if the page is not normally bookmarked see links below). Further to this, if you are looking to store large amounts of data in the scopes, use java objects rather than javascript objects. eg using a java hashmap to store values/objects is significantly better memory wise than using a javascript object to do the same.

Links
Try to use direct url links as much as possible instead of actions behind links. Aside from usability, bookmarking and accessibility reasons there is a lot less processing involved (so using a GET for a link as apposed to POST with an action is loads better for performance and memory). Related, do not go overboard on storing "navigation" variables on the sessionScope. A link to the page from elsewhere etc will not have that information so navigation will fail.

Partial Refresh
Use Partial Refresh where ever possible so only that portion of the JSF tree is processed.

Data Scope for a view
When you add data sources to your XPage, each one has a "scope". Its set under All properties, data, name, scope.

The default is "viewScope" (data is stored as part of the page). If you want to cut down on as much memory usage as possible, and you are not relying on pass through parameters like a filter or a search (so need to persist for pagination) it is possible to set this to "request". This will release the memory used when the view is served to the browser. In 8.51 (usual caveats) there is a new option here so only do this if you are being ultra vigilent with your memory usage.