Hello, we're currently trying to plan moving our sites to Umbraco and need help with the architecture.
There are roughly 10 sites, each with roughly 15,000 pieces of content each (anywhere between 1 and 20 new pieces of content added daily to each site) serving out a combined total or roughly 10 million page views per month. There is a requirement that these sites be able to share content in that when viewing an article on one site there may be a list along the lines of "other similar articles from our sites".
The question is how best to architecture this with Umbraco? Is this too much content / load to place within a single Umbraco instance? If so, we'd look at an individual instance for each and a seperate web service or similar to search all the databases for related content.
Two things: If you get support the Core Team/HQ will give you architectural counsel as stated on the product page, next I recently watch Per on umbraco.tv give a great presentation of how umbraco works how the xml tree is generated and cached. He even provided several architectural diagrams of such. Overall depending on your need it may be worth the $ for pro support to get the info you need to make an educated decision. Just give the HQ a call Neils has been excellent assisting our organization answer key questions without spending a dime.
John, this much content can definitely be handled by Umbraco, but I would recommend having the content in so-called "Date Folders" so that the Umbraco backend is most responsive.
Also, if the presentation of your sites is very similar, it's fine to use the same Umbraco instance for all of your sites, but I would create different instances for sites that have very different layouts and/or document types.
If you do go with a single instance, it's easy to create different sites in your content tree. Just create a document type with site specific settings (like the Analytics code and maybe a logo image or whatever) and create the content tree like this:
Content: - Site1.ext - Site2.ext - Site3.ext
.. and so on. On eacht of the sites you can right-click and manage the hostnames. Don't forget to set up the same hostnames in IIS for that instance as well.
With XSLT it's very easy to stay within the context of just the single site that the user has entered, just make sure you don't select anything higher up than level 1 (in relation to the $currentPage variable). But if you do need to get content from your other sites, you can of course go higher than level 1 and branche out to the other sites with (in 4.0.x: $currentPage/ancestor-or-self::root//node or in 4.5.x $currentPage/ancestor-or-self::root//* [isDoc] you get all of the nodes within all of your sites).
Kevon, do you know which video had this? I've got a video subscription.
The other issue is that the sites will potentially have a lot of user generated content (profiles, galleries, forum threads, etc) which has to be live (published) straight away. I know that when updating a single property for a document that each time it creates a SQL UPDATE command and that creating a document with a lot of properties can be slow. I worry that situations like this will bring down the performance of the site.
The video was entitled XSLT in Umbraco. As far as SQL updates thats every CMS. I cant advise on Load Balancing or SQL Optimization because every scenario is truly different... but what I do know is that Umbraco has the API/Object Model needed to extend data integrity and redundancy. Umbraco even has a OOB REST based client/server model so you can better handle client processing (check out the \base videos). So I hope this helps. Oh yeah the developers over at CondeNast use Umbraco, and they're a media powerhouse... they have some vids on vimeo I believe, if you need architectural advice they certainly would know, maybe you could get a hold of one of them in the community.
John: with regards to user generated content: we're just doing our own custom tables for that and access them through Entity Framework. Then we have XSLT extensions that provides XML for the data in those tables. You can then easily cache the XSLT macro's (or usercontrol macro's, if you decide to use them) to make sure performance is not affected. You can cache very granularly, so publishing immediately doesn't have to be a problem.
Yep, thanks Sebastiaa. Custom tables will be used for items like user comments but for items like profile pages, forum threads, etc they have to be pages and thus have to be nodes.
Interesting, I'll have to look into how easy the URL rewriter in Umbraco is. It's not an ISAPI filter so I guess it just captures the request in a global.axax file or similar.
The only problem here is that as well as custom XSLT extensions it means custom admin controls, etc which kind of voids some of the benefit of using a CMS.
I very much agree John, but it's a bit of a trade-off. You should wonder how much of the user generated content really is content manageable content though. 99% you shouldn't have to touch content that people put in.
The solution for editing other people's content is quite simple: do it in the frontend. If you're logged in as an admin, you can use all the editing features that your members can use. Instead of just your own content, and admin could be able to edit all of the content.
Umbraco Architecture
Hello, we're currently trying to plan moving our sites to Umbraco and need help with the architecture.
There are roughly 10 sites, each with roughly 15,000 pieces of content each (anywhere between 1 and 20 new pieces of content added daily to each site) serving out a combined total or roughly 10 million page views per month. There is a requirement that these sites be able to share content in that when viewing an article on one site there may be a list along the lines of "other similar articles from our sites".
The question is how best to architecture this with Umbraco? Is this too much content / load to place within a single Umbraco instance? If so, we'd look at an individual instance for each and a seperate web service or similar to search all the databases for related content.
Two things: If you get support the Core Team/HQ will give you architectural counsel as stated on the product page, next I recently watch Per on umbraco.tv give a great presentation of how umbraco works how the xml tree is generated and cached. He even provided several architectural diagrams of such. Overall depending on your need it may be worth the $ for pro support to get the info you need to make an educated decision. Just give the HQ a call Neils has been excellent assisting our organization answer key questions without spending a dime.
Hope this helps.
John, this much content can definitely be handled by Umbraco, but I would recommend having the content in so-called "Date Folders" so that the Umbraco backend is most responsive.
Also, if the presentation of your sites is very similar, it's fine to use the same Umbraco instance for all of your sites, but I would create different instances for sites that have very different layouts and/or document types.
If you do go with a single instance, it's easy to create different sites in your content tree. Just create a document type with site specific settings (like the Analytics code and maybe a logo image or whatever) and create the content tree like this:
Content:
- Site1.ext
- Site2.ext
- Site3.ext
.. and so on. On eacht of the sites you can right-click and manage the hostnames. Don't forget to set up the same hostnames in IIS for that instance as well.
With XSLT it's very easy to stay within the context of just the single site that the user has entered, just make sure you don't select anything higher up than level 1 (in relation to the $currentPage variable). But if you do need to get content from your other sites, you can of course go higher than level 1 and branche out to the other sites with (in 4.0.x: $currentPage/ancestor-or-self::root//node or in 4.5.x $currentPage/ancestor-or-self::root//* [isDoc] you get all of the nodes within all of your sites).
Thanks guys, good advice.
Kevon, do you know which video had this? I've got a video subscription.
The other issue is that the sites will potentially have a lot of user generated content (profiles, galleries, forum threads, etc) which has to be live (published) straight away. I know that when updating a single property for a document that each time it creates a SQL UPDATE command and that creating a document with a lot of properties can be slow. I worry that situations like this will bring down the performance of the site.
The video was entitled XSLT in Umbraco. As far as SQL updates thats every CMS. I cant advise on Load Balancing or SQL Optimization because every scenario is truly different... but what I do know is that Umbraco has the API/Object Model needed to extend data integrity and redundancy. Umbraco even has a OOB REST based client/server model so you can better handle client processing (check out the \base videos). So I hope this helps. Oh yeah the developers over at CondeNast use Umbraco, and they're a media powerhouse... they have some vids on vimeo I believe, if you need architectural advice they certainly would know, maybe you could get a hold of one of them in the community.
John: with regards to user generated content: we're just doing our own custom tables for that and access them through Entity Framework. Then we have XSLT extensions that provides XML for the data in those tables. You can then easily cache the XSLT macro's (or usercontrol macro's, if you decide to use them) to make sure performance is not affected. You can cache very granularly, so publishing immediately doesn't have to be a problem.
Yep, thanks Sebastiaa. Custom tables will be used for items like user comments but for items like profile pages, forum threads, etc they have to be pages and thus have to be nodes.
They don't really have to be nodes though, with a little bit of URL rewriting you can do a lot! :-)
(for example, I believe these forum pages really aren't nodes)
Interesting, I'll have to look into how easy the URL rewriter in Umbraco is. It's not an ISAPI filter so I guess it just captures the request in a global.axax file or similar.
The only problem here is that as well as custom XSLT extensions it means custom admin controls, etc which kind of voids some of the benefit of using a CMS.
Your help is really appreciated guys, cheers.
I very much agree John, but it's a bit of a trade-off. You should wonder how much of the user generated content really is content manageable content though. 99% you shouldn't have to touch content that people put in.
The solution for editing other people's content is quite simple: do it in the frontend. If you're logged in as an admin, you can use all the editing features that your members can use. Instead of just your own content, and admin could be able to edit all of the content.
is working on a reply...