Step by Step, Little by Little (3)

Posted on July 28, 2015 in umbraco

Reporting from the NuCache front. This site has been running NuCache (aka "Le Cache Nouveau") for a couple of months now, being regularly upgraded, without problems. The FIXME comments in the code have been massively cleaned up, and development has entered a debugging and tuning phase.

Where is the code?

Everything is publicly accessible in the dev-v7-contentcache branch, which basically is 7.3.0 + content cache. However, as discussed during CG15, the target release is most probably v8, and so it is expected that not everything is 100% backward compatible with 7.3.0.

We have been able to upgrade a few sites during CG15, but that can take a few hours fixing things here and there. Some packages (eg SEO Checker) are known to break. There are not "massive" changes, but some event signatures change, some renaming, etc.

Refactoring the content cache has some collateral "advantages": in order for the cache to remain consistent under heavy stress tests, other parts of Umbraco have had to be cleaned up, including services, database accesses, etc. But this also implies a few breaking changes.

The plan is to have a complete list of these changes at some point, in order to facilitate upgrades.

Local database

NuCache now runs with a local database, much alike the venerable umbraco.config file. The main difference is that we do not rely on a big Xml file, but on a powerful key-value store powered by CSharpTest.Net.Collections BPlusTree, which seems pretty stable so far.

A key-value store offers better granularity: instead of periodically serializing an Xml dump of the entire content tree to disk, as was the case with the umbraco.config file, we can update the local store on the fly and rely on binary serialization. When Umbraco restarts, the entire cache is reloaded from the local store and not from the database.

And of course, this also applies to medias, which are now cached exactly in the same way contents are, and do not depend on Examine/Lucene anymore.

Not only my site, but Our site

During CG15, a new version of Our was released. First, it brings a new UX that one can love or hate but, more importantly, that one can fix and maintain: the number of commits in the Our source repo since CG15 is amazing. Second, it runs on the latest stable release of Umbraco (7.2.something).

Which makes it an ideal candidate for NuCache... No no no, Our does not run on NuCache in production! But it does run pretty well in my dev environment. Including most of the fancy über-legacy code and Xslt macros.

Perfs

I still have to write a post with some benchmarking numbers, but NuCache is faster. It's super-cool to be able to edit this post, hit Ctrl-S, change tab, hit F5 and immediately see the post's preview. In fact, I realize that, as an editor, I almost exclusively navigate the site in preview mode.

Having Our on NuCache is interesting because of the legacy Xslt macros. I am currently assessing the performance impact of NuCache on these macros—more later.

One facade to rule them all

We have always had a front-end content cache and media cache, both returning IPublishedContent objects. We also have a front-end member cache, providing a unified access to members.

The facade is the Umbraco layer that provides access to all those front-end caches and services. It is only a word: there is no "facade" class of any sort. And I am only mentioning it here to introduce the concept and let it sink in people's mind.

Next?

Two "architecture-level" items: improving how we exposes Domains and cultures, and improving the inner routes cache that maps an url to a content and vice-versa. Other than that, it is mostly testing, profiling, debugging and tuning.