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!

6 Responses to Tuning your XPages…

  1. Thank you. I found this very interesting and will put this into my applications.
    I’m currently working on moving an entire intranet online in xpages and will have 60 users live almost all the time. They also love to open many man pages. so this is most helpful.

      • I didn’t think so, but another company I do work for, is looking at moving about 50 applications to XPages and they are over 600 users! Now thats going to be interesting. They use many of these applications the whole day, all the time non-stop. I still think that it should not be a problem with some clever coding 😉

      • I agree. I think that the most important thing is that we now have a LOT of control of how the web engine handles our workload. And we need to understand some of the fundamentals to not overburden the server with work that we really do not need.

        So the “clever coding” mostly means knowing what we do – and CAN do with the platform. This is a HUGHE difference from the traditional Domino web development – and there is a lot for us all to learn and understand.

  2. I have worked with applications that support 100’s of concurrent users and potentials of thousands with no issues just ensure the server has plenty of memory and enough processing power

    • That is exactly where we landed. As long as the architecture does not have bottlenecks in the way it retrieves data then we can just add more hardware 😉

      I have built traditional Domino web sites (intranet) in the past with 10,000’s of users. Worked like a charm. But the thing is that with the XPages engine we are dealing with a different creature – and I still haven’t had systems of the same size running on XPages. But I am confident we can handle it – should we get that many users 😉