Tuning your XPages...

Ok this may promise a little more than I can hold.

However, I just wanted to point the attention to some good advice that I had from Tony McGuckin (co-author of Mastering XPages) at IBM Connect 2014 in Orlando. This piece of advice surfaced through a review of a large application that I was building - and whether the architecture would "hold water" should the application become very popular. The basic concept is that we cache all data in memory in the form of Java objects. I have told about this previously in presentations/articles on MVC and caching.

Tony gave me three pieces of advice to follow to ensure that the application would be able to scale:

1. viewState

This is a very interesting setting. Basically, for pages where you write data back to the server you should use "full" (which is the server default). This will maintain the component tree so the server knows what you are working on (e.g. knows the state of the entire page when you do a partial refresh). You may have to watch the setting "Maximum pages on disk" (in the XPages properties) as well since it determines how many "steps" of the component tree that the server keeps. The default for 8.5.3 is 4 (four) pages. This has been increased to 16 for version 9.0. Normally, this setting will suffice - however, a certain usage pattern can blow you out of that number of pages. If a user opens a page in a new window to check some information for the form they are filling in - then you quickly pass even 16 steps (~pages).

Ok, back to "viewState". You can set this for the entire application in the XPages properties under "Persistence" where it is named "Page persistence mode" (the actual property is: "xsp.persistence.viewstate"). I doubt you will want to set this setting application wide. This would only apply to a "normal homepage" where you only present information. Most of the XPages solutions I see do have some interaction with entering data in them. However, you can set this setting on each XPage. You will find it under "All properties" for the XPage.

The viewState can take 4 different values. Default is "fulltree". In this situation you are used to. You can use "delta" which will only keep "current doc in memory". This setting as well as "deltaex" are for advanced uses - and only applies when using RAM persistence - exclusively! Have a look at page 1033 in the Mastering XPages book (2nd edition) for more details if you need to consider these. Finally, you could set viewState to "nostate". This, however, is a very useful setting in many cases. If you have a "readonly" page in your application (e.g. the landing page) you should consider not saving any state for it. Another splendid example is an "XAgent" (which is an XPage that is not rendered - typically used as a "service" to provide e.g. JSON data).

2. Short session timeout

The second advice is to have a low session timeout. Now why would one do that? then we will loose all the data in the user's session and have to reload it if needed. You may actually think that it is better to put the session timeout UP to avoid any problems while the user is working (e.g. timeout while they are entering data....). Well, the problem with sessions is that if the user just closes the browser (and don't do a proper logout) all of the session data is kept in memory until the session times out. So with an application with many users you may quickly end up short of memory due to many "dead" sessions waiting to time out to free their memory. This is the same reason why you want to be careful not to put more data in the session scope than needed.

A better approach then is to put the session timeout DOWN. I use 5 minutes. And then combine that with a "Keep session alive" mechanism (there is one in the XPages Library - or you can build your own). Basically, this just initiates an AJAX call in the background to "touch" the server to let it know that you are alive. As long as it does this just before the session time out it will keep you going for long.... On the other hand, users that close their browsers without logging out will have the sessions recycles within 5 minutes freeing up ressources for new users.

You find the session timeout in the XPages properties on the "General" tab. You set a number of minutes. The name of the property is: "xsp.session.timeout".

3. Long application timeout

There is only ONE application scope for an application (as opposed to the session scope). Therefore, it makes sense to put the application scope timeout UP. I use 300 minutes. This way you can keep all general stuff ready at hand all day. I cache a lot of data in the application scope in a large application at present. This means that it is blistering fast - even for the first user (since I cache the information prior to the first user hitting the application). And once the data is cached it stays there.... I don't really want to "waste" the effort of reading all the data into the application scope too soon. Of course, you will need to implement a proper mechanism to maintain the cache current if you do any updates - but that is a totally different topic.

You find the application  timeout in the XPages properties on the "General" tab. You set a number of minutes. The name of the property is: "xsp.application.timeout".

I hope that you can use the above to tune your applications - or at least I may have brought some aspects to your attention that you can then investigate for your own purposes.

Happy coding!