Road ahead for "the new cache"
Lars-Erik Aabech
TLDR; The new cache uses excessive CPU. It’s not meant for front-end use. This is a call for discussion about how to effectively use entities other than content and media in the front-end.
I've been researching performance issues with a site we've upgraded to 7.3. It had gotten higher CPU load than usual and sudden HTTP queue buildups.
After profiling and load-testing we've identified and mitigated a few new issues in Umbraco, and the site is now running with "normal" CPU usage and can handle the load it had before.
(The queue buildup might be unrelated)
Our installation is a multilingual, multi-site/domain solution integrated with UCommerce.
In all pages, we use the services on UmbracoContext.Current.Application.Services directly or indirectly to get domains, languages, dictionary items etc. There's also quite a lot of links to misc. content, which generates URLs, which indirectly uses the domain service. And we need to iterate domains and content to find the correct UCommerce store.
There's also a couple of cases where we use public access, which have also been refactored.
Turns out these services weren't really intended by HQ to be used heavily from the front-end. Never the less, they've been used all over the place in methods that _are_ intended for front-end use, since the legacy APIs are being factored out.
Beneath the services are a new cache similar to identity maps and L2 cache in ORMs. It should do wonders for the backoffice, but it is really CPU intensive when used from the front-end, or with multiple GetAll() calls. (I’m sure a profiling of the backoffice is due anyway. J )
So Umbraco continues to perform well with sites that don't need any fancy business logic, and don't do very much URL building.
But in our case, it’s really really bad.
To limit the CPU usage on our site, we've replaced the built-in repositories for domains, languages and permissions.
Here's a git repo with those. https://github.com/lars-erik/naive-umbraco-cache
I've been going through this with HQ and we agreed that the way forward is a good case for the dev. mailing list.
Currently, the cache for the mentioned entities is one big dictionary where the keys are a combination of the entity type and it’s ID. For instance “_repo_Language_12”.
To get all languages, the keys are enumerated and if they start with “_repo_Language”, the value is put into a list.
Of course this means that any successive call to any GetAll() will iterate the entire dictionary, and not be very “cachelike” at all.
My suggestions for improvinig the cache, and/or creating a new front-end read-only cache of business data is as follows:
- Put each entity type in it’s own dictionary to prevent key/type thrashing
- Publicize/open up the base repository classes and allow for individual caching strategies
o Provide some guidance for overriding the default repos / caches
- Always return IQueryable from GetAll()
o Depending on count of entities in the DB
§ return an ORM compatible queryable that goes to the database
§ return the entire list of entities from memory, without thrasing keys.
- Either
o Do this to the existing repos
o Create a new “read-only” API for use in the front-end
I guess some of this can’t be done until v8, but it’d be nice to spend the time before making sure we have a really really well cached foundation to build our business-logic with.
(And hopefully a few improvements along the way)
Lars-Erik Aabech
Faglig leder utvikling
MarkedsPartner AS
www.markedspartner.no
+47 920 30 537
Shannon Deminick
Lars-Erik Aabech
GET urn://continued-discussion-about-cache
302 Found
Location: http://issues.umbraco.org/issue/U4-7558
J