Maximum number of subsites in Umbraco

Question

Problem:

Some company has 20 sites, and wants to manage these within a single CMS instance.
There are many solutions possible, but one I'm investigating is a single Umbraco instance with 20 subsites.

I only have experience with Sitecore and Sharepoint (in these quantities).

Now my question is; how does this perform in Umbraco (latest version)?

Does anyone have real-life hands-on experience with this order of magnitude?
My personal maximum with Umbraco is 3 subsites on low- to medium-traffic sites.

Answer 1

I'm currently running a single Umbraco install with +800 sites and +20.000 content nodes, and Umbraco was running fine until about 200 sites and 5.000 nodes, after that point we started experience strange behaviors with some specific back-office tasks. Ex. changing a doctype that is used by many nodes, can cause some unwanted frontend effects, like missing content etc. (see more info here http://allan-laustsen.blogspot.dk/2012/03/umbraco-no-node-exists-cmscontentxml.html) But we have modified some of the source of Umbraco to be able to handle a higher amount of nodes and sites, and it's running smoothly so far. So I dont know what the "limit" is (yet)

Answer 2

I have struggled with this myself. I have about a dozen subsites in one Umbraco install, so not as many as you, but one of them has a products section with individual pages for more than a few thousand products, so quite a few total pages.

Performance is fine for me, but here are a couple (among many) things to keep in mind:

1. any queries in razor / xslt must be written to target the most specific to most general. At first I had some query that was getting all of the "blah" pages. Well this will enumerate the entire site looking for those pages. If it was for a site that was very small, it would be slowed down by the site with the 3000+ product pages. So you have to carefully target a specific node and then go from there (in my case, traverse up the node tree to "subsiteHome" page, and then get all the children from there of type "blah").

2. The whole point of containing them in this way was to make maintenance easier and to share assets among sites. Well if you're adding some new feature to one of the subsites, and it needs the latest version of a certain package, you have to be prepared to update all of the other subsites that make use of the package. ie it can (depending on the scale and complexity of your subsites) become a bit of a balancing act.

In the end, I don't think performance of an Umbraco install with 20 subsites with, say, 100 pages each would be much different from a single site with 2000 pages, but you have to be careful in how you query / fetch the content (via razor / xslt queries), and whether the benefits to maintenance are real or not.

Answer 3

Within the Umbraco interface itself, the larger and more complex the site, generally the slower it will perform. I say this purely because of the likelihood of an increase in complexity of the project as a site structure grows. This is not always the case but I built a site that was multi-territory, multi-site, each having multi-languages and whilst the published site performed fine, the interface more often than not performed badly. Having said that, I would love to go back and check and revise my code!

Hits to the database are the worst offender. Generally the published content shouldn't have to make any db calls as all publisjed content is cached. However, the minute you create a macro, usercontrol, view, data type that queries the Umbraco API to retrieve Document, Content, ContentType, DocumentType or Media objects, then you are hitting the database.

If you do this in code that is called often, e.g. a HttpModule, then your performance will suffer, both in the published site and back office. Obviously, its unavoidable sometimes and so you just have to be careful and implementing some caching is invaluable.

I should also point out that the currently Umbraco v6 is in beta and has revised the API massively implementing PetaPoco. Whilst this won't mitigate for coding cock-ups we make as developers, it will make the API much slicker than it previously has been!