Subscribe via Feed

Writing Efficient & Scalable XPages

Mark Gargan, Aug 9, 2009 11:13:00 PM

I spent quite a bit of time recently profiling and optimizing an xpage application I've been working on. I needed to be quite ruthless, every fraction of a millisecond counted, so I dug deep to squeeze everything I could out of it. The application was tested for client performance, as well as on the server while under load. Here are some of the tips and tricks used to optimize my application. Steve Castledine has already made some excellent comments on xpage performance on his blog in this post XPages Memory Usage and Performance Tips - 8.5.

Use the correct container

Be careful not to over use , if you not displaying or editing data use . If you don't need any xpage functionality such as themes or computing visibility then consider simply using a HTML

. If you are using but it's contents are read only be sure to add the attribute readonly="true"

Avoid unnecessary computations
This might seem obvious, but while profiling my application I found that there were a lot of calls that could have been made once at load time, externalized or even simply hard coded. For example, I was displaying the name of the application, it was a computed field with @DbTitle as its value, I replaced it with a hard code string since it never changed, a small saving but when there are several of them and the server is under high loads they add up.

Serve static resources from disk

From client side and server side this can potentially offer the greatest overall improvement. Having all the resources such as images, css and client side javascript, nicely wrapped up in a nsf is a great way to share and quickly deploy an app. Unfortunately there is additional overhead serving the content from the nsf. Instead consider placing them on the disk, somewhere under the .../domino/data/html/ directory. It may require a little be of a rework of your app but it is worth it for a fully deployed app, using themes can help reduce the effort.

Use Partial update

Use partial update whenever you can. One, it gives the user the impression of better performance and two, it reduces the work load on the server. There is a lot more I can say here but I think it warrants a post of its own so I will return to the topic in the near future.

Less controls

Avoid having too many custom controls. When a control is loaded there are several java new calls, which are relatively slow. If you can roll several controls into one, do so. For example if you have a sidebar control that always has the same three controls in it, roll them into one sidebar control.

Themes

Create your own themes from scratch. Creating a theme that extends from the webstandard or another supplied theme will include extra stylesheets and styles that you might not need. Be prepared to spend more time writing css though.

$ vs #

Whats the difference? #{javascript:...} is called at render time, whereas ${javascript:...} is called at load time. Use $ when the value computed is not going to change once the xpage is loaded, this is particularly usefully when using partial updates.

Scopes
Generally I try to avoid using any of the scopes, but when I do use them it tends to be for data I want to store long term e.g. the user session. If you are using any of the scopes, be sure to use the scope with the shortest span you need and clear variables once they are no longer required

HTML optimizations
From the client point of few, general HTML optimizations apply to XPages as well. Make sure all your javascript and css files are minified, use sprites and long expiry headers on static resource such as images. Tools like YSlow & FireBug are great for analyzing your pages.

Data source vs @Functions

For small views, such as a Table of Contents view consider using @DbColumn instead of a data source and repeat control to access and display the data. For small views there is a small gain but it adds up when your application is under load. The downside of this is it is more difficult to render the data nicely and its not a generic solution.

Ad Hoc Caching

This was a sneaky suggestion someone else came up with, we generated some data from a view then stored in it in the session scope. The data was always pretty small so we thought it would be better to take the hit in memory rather than having to calculate the data ever time the page was loaded. Again this is not really a general solution, but one I thought worth mentioning.

That's about all the tips I can think of for the moment, as I come across more I'll try to update this post, or make additional post. Originally posted on my blog here



2 responses to Writing Efficient & Scalable XPages

Mark Gargan, August 16, 2009 11:23 AM

Hi Rob, yeah partial updates are AJAX calls. The request contains the id of the control to be redrawn, innerHTML of that control is generated and returned to client which updates the page.

Nice idea with the agent to deploy the resources.

Mark


RobShaver, August 10, 2009 6:00 PM

I'm new to XPages so these are useful. What are "partial updates"? Is this like using AJAX to update a list box with individual calls based on the actions of the user?

@Serving static resources from the disk - The way I've done this on databases that get distributed is to store the resources in the database and then have an installation agent that copies them to the correct location on the server. It isn't that hard as long as you build a manifest document that tells the agent what resources go where. This aids maintenance and serves to document the required resources.

Thanks,

Rob:-]