While doing XPages application performance optimization, I discovered that one of the slowest parts was reading the template version and build date. I've never paid much attention to this code, so it surprised me.
The code that we used was the standard code to get it
NoteCollection noteCollection;
noteCollection = db.createNoteCollection(true);
noteCollection.setSelectSharedFields(true);
noteCollection.setSelectionFormula("$TITLE=\"$TemplateBuild\"");
noteCollection.buildCollection();
final String noteID = noteCollection.getFirstNoteID();
...
But in this application, it normally took around 2 seconds just to call this noteCollection.buildCollection(). What was even worse, the first call of the day took 20s. I wasn't able to reproduce the 20s even after server restart, so that's still a mystery to me. The application is not huge - around 200 design elements and 100k normal document. 600MB in size.
I started to look for alternative approaches and a simple hint from HCL set me on the right track - can we use a view to get this information?
Yes, you can customize a view to show design elements by adjusting $FormulaClass e.g. using LotusScript or ScanEZ. This way I created a view with:
$FormulaClass = 1024
Selection formula = SELECT $Title="$TemplateBuild"
and columns to show the $TemplacteBuild and $TemplateBuildDate
Then the code got even more simple :
View v = db.getView("($dbversion)");
ViewEntry ve = v.getAllEntries().getFirstEntry();
version = ve.getColumnValues().get(1).toString();
versiondate = ve.getColumnValues().get(2).toString();
Now the code gets the version instantly (I've seen numbers around 60ms at most). I can probably even set the view to "no refresh" as all the templates are fully recreated in CI/CD environment, so the design is completely replaced every time.
We have such code in all application, mostly being read into an app-scope bean, but in some cases, it's just a customControl that's displayed somewhere on all pages. Nobody ever worried about performance.
Comments
Post a Comment