The nine reasons Quickr 8.2 performance rocks the house
Category Lotus QuickrWhen Lotus Quickr 8.2 was released a couple months ago, a number of folks in the blogosphere, Facebook and Twitter noticed significantly faster page loads, crisper folder and view refreshes and an overall more satisfying web experience than with the look-alike Quickr 8.1 or any prior version. Even Simon gives it a thumbs-up.
Initially, out of curiosity I loaded up Firebug with all its accoutrements and checked out the page and element sizes. I measured a major decrease in code loading between 8.1 and 8.2 and claimed a 206% performance boost just from this. Unsatisfied at the simplicity of the explanation, I consulted with Miki Banatwala at IBM, Quickr's chief programmer. He has helped to fill in the blanks with some bullet points, and I'll expand on them here.
Note that these are product improvements only - for a truly performant Domino and Quickr experience, you need to tune and apply best practices to your installation. Much of what IBM does to improve performance is unfortunately nullified by companies who ignore this aspect of server administration, electing for out of the box installs. I'll write more about performance tuning (and if you follow me on Twitter @LotusRockStar, you know I'm posting tips!) but of course your best opportunity to learn more about improving Quickr performance is at Collaboration University, where Gabriella Davis, Warren Elsmore, Chris Miller and myself will all have materials on this topic.
That said, on to IBM's improvements and (my comments in italics) what they mean!
Server side:
- Some DbCommands are now interpreted/re-written
as tags and their evaluation has been streamlined, as well collapsing the
commands to be handled this way
In Quickr, there is a special version of @DbCommand that processes Quickr-specific calls. You probably don't know this, since even deep inspection of the code only reveals them as Base64 encoded strings (the previous way of making them faster). Now, by rewriting them as tags and putting the logic into the Domino http stack for interpretation, database command calls are avoided freeing up resources.
- Tightening of code paths (mostly
targeting the main use-cases - focused on things like login, first visit,
landing page, doc library navigation, page reads etc.)
Anytime IBM says code paths, they mean something deeper than we tend to think about as web developers. This means, in essence, that at the C interpretation level that the code has been streamlined. For instance, if you consider the login path for Quickr, it has evolved significantly since the nquickplace.dll DSAPI flter method. With Domino handling the logic, it's faster, and now by tightening up that process there are fewer code hoops to jump through to get logged in.
- Streamlined rest/web service code
paths
Ditto!
- Stat thread management streamlined;
multiple threads were writing to the same db - now consolidated
Fairly self-explanatory, but for the layman a "thread" results from a fork of a program into two or more concurrently running tasks (thank you, Wikipedia). Multiple threads opening the same database, bad.
- File Cache cleanup
When the server caches files, they can be served up from the file system faster. With old or outdated files left on the file system, it takes longer to find the right file. Clean those up, and it's faster.
Client side:
- Put the right expiration headers
as needed
Sounds more like an "oops" to me, but considering the 550+ subforms that make up Quickr, understandable.
- Reduced number of requests to the
server by putting info in main content
Front-loading some of the more intense operations, considering the new Juicer (see below), allows the client to make fewer requests to the server. Local processing of functions against local variables and data is 100x faster than asking the server for it.
- Changed the user experience a bit
to not load editors on main page
Previously, the ActiveX editors (I know, I know, wait for Quickr Next!) would load when you logged in. Now, it doesn't try until it determines you may need them. So users without a need for them or who do not hit a page that would require them are not "stopped at the gate."
DRUMROLL PLEASE FOR THE BIGGEST PERFORMANCE IMPROVEMENT - A BRILLIANT IDEA WELL IMPLEMENTED...
- Combined js/css and gzipping artifacts
(this proved to be really helpful since the combining actually produces
a zip artifact that can be streamed right away after the very first user
requests it)
This is absolutely the biggest deal from the user's perspective. What this means is that if your Quickr page, form or folder normally loads three external JavaScript files, now those three are passed through the Quickr servlet to a) combine them, b) gzip the result, then feed that highly compressed (read: waaaaay smaller) file out to the browser to cache and use. And the big kicker, only the first user has to hit a page for this to happen, then the combination file is now cached on the server for other users! I call this feature the Quickr Juicer (a la infomercials - get all the benefits in a smaller package!)
But that's another blog entry. For now, just consider the impact of supporting more users concurrently with the core product, go forth and install!
