tl;dr – If you have the “compute” option of a document datasource enabled, make sure:
- The underlying form does not have fields perform a DbLookup to a view that has @Today or @Now in a column/selection formula.
- If the form has embedded views, make sure the column/selection formulas of the view do not utilize @Today or @Now.
For the past year+ I’ve been in the midst of modernizing a very, very large Lotus Notes application that is comprised of many databases. Over the past few weeks, as I started building out the next phase, one particular XPage was loading extremely, EXTREMELY, slow, like in the neighborhood of 8 seconds to open. Not good.
Since we are modernizing an existing application (which is the lifeblood of the company), we are operating in a co-existence environment. This means dropping the XPages layer on top of the existing environment versus building and architecting an application from scratch. So in this case, the XPage in question has a document datasource that utilizes an existing Notes form.
After examining the XPage and determining that the performance issue was not there, I turned my attention to the underlying form. I do have the “compute” option turned on:
Now, keep in mind I did not build this form originally, so I am getting up to speed with it’s inner workings as I’m building out the XPages side.
My discovery process went something like this:
“There are 3 embedded views. Ok. No Problem. Lots of Notes forms have embdedded views.”
“This column of the first embedded uses @Today. That’s bad.”
“Wait … every embedded view has a column with @Today? WTF!! OK, we can deal with this.”
“This field is doing a lookup to a view with @Today … and this field … and this field.”
Using @Today and @Now in a view is bad enough … but six times on a form? OUCH!
This was a flat-out performance catastrophe. One of the first performance tips you learn in Notes Client development is do not use @Today or @Now in view column or selection formulas unless you absolutely have to. Even then, consider running an agent nightly to update the view with a hard coded date instead.
Luckily, the issue was discovered and handled, reducing the page load time from 8s to ~50ms.