I am fairly confident that Umbraco and MVC will scale well with large websites (given sufficient power for the back end db).
However, reading some old posts, someone mentioned 'don't have too many child nodes per parent'.
Just a question : if you do put large numbers of first level children would that affect performance (I would have thought not as we would be using a SQL db so fetching lists of documents shouldn't be a problem?) or is just a case of it would simply be unmanageable in the back end ie finding documents to manually edit and so on?
Shouldn't be a problem. For very large lists (e.g., hundreds or thousands of nodes), Umbraco now supports a "list view". That provides a paged/searchable interface to explore the large list of nodes.
The frontend of the website should not even be hitting the database for the most part. Umbraco builds an XML cache of the entire content tree and uses an in-memory version of the XML file to fetch information about content.
If you write code that is not performant (e.g., scans all child nodes on each page render), then that of course would be an issue, but there are many caching techniques that can be used to fix those types of issues.
Yep, if you loop through all children and you just so happen to have hundreds or thousands of children, then that could potentially take 1+ seconds (i.e., it would be slow).
There are a number of simple strategies you can use to avoid that slowness. For example, do that scan of children once, extract whatever data you need, then store that (e.g., in a static variable).
There are a number of simple strategies you can use to avoid that
slowness. For example, do that scan of children once, extract whatever
data you need, then store that (e.g., in a static variable).
How do you mean : having delivered the page to the browser that data is lost, isn't it? You couldn't then re-use it (eg for pagination) without loading the page again and doing the scan again?
Here's what you do. Create some class somewhere. Create a static variable on that class that is a dictionary. The dictionary key would be an ID (i.e., the ID of the parent page). The value would be a list of PageInfo (i.e., the child pages of that parent page). PageInfo is another class you'll create. It will contain any variables you need (e.g., page name and page URL).
When you render the page, you'll first check the dictionary to see if it contains the key for the current page's ID. If so, use that data. Otherwise, loop through all the child pages and convert them the instances of PageInfo. Add that list to the dictionary with the current page's ID as the key.
Next time the page is rendered, it'll use your dictionary as a cache rather than relying on Umbraco's content nodes.
Note that static variables remain intact across web requests, so they won't simply vanish when the page has rendered. Also, they're shared across all users, so you'll want to implement some locking mechanism to prevent any thread concurrency issues (e.g., two web requests attempting to modify the dictionary at the same time).
Scaleability and 1st level child nodes
I am fairly confident that Umbraco and MVC will scale well with large websites (given sufficient power for the back end db).
However, reading some old posts, someone mentioned 'don't have too many child nodes per parent'.
Just a question : if you do put large numbers of first level children would that affect performance (I would have thought not as we would be using a SQL db so fetching lists of documents shouldn't be a problem?) or is just a case of it would simply be unmanageable in the back end ie finding documents to manually edit and so on?
Shouldn't be a problem. For very large lists (e.g., hundreds or thousands of nodes), Umbraco now supports a "list view". That provides a paged/searchable interface to explore the large list of nodes.
The frontend of the website should not even be hitting the database for the most part. Umbraco builds an XML cache of the entire content tree and uses an in-memory version of the XML file to fetch information about content.
If you write code that is not performant (e.g., scans all child nodes on each page render), then that of course would be an issue, but there are many caching techniques that can be used to fix those types of issues.
Thanks
You say If you write code that is not performant (e.g., scans all child nodes on each page render),
would that include a page that lists a particular set of documents eg
node.Children()
Yep, if you loop through all children and you just so happen to have hundreds or thousands of children, then that could potentially take 1+ seconds (i.e., it would be slow).
There are a number of simple strategies you can use to avoid that slowness. For example, do that scan of children once, extract whatever data you need, then store that (e.g., in a static variable).
How do you mean : having delivered the page to the browser that data is lost, isn't it? You couldn't then re-use it (eg for pagination) without loading the page again and doing the scan again?
Or is there some clever way to to re-use?
Here's what you do. Create some class somewhere. Create a static variable on that class that is a dictionary. The dictionary key would be an ID (i.e., the ID of the parent page). The value would be a list of
PageInfo(i.e., the child pages of that parent page). PageInfo is another class you'll create. It will contain any variables you need (e.g., page name and page URL).When you render the page, you'll first check the dictionary to see if it contains the key for the current page's ID. If so, use that data. Otherwise, loop through all the child pages and convert them the instances of PageInfo. Add that list to the dictionary with the current page's ID as the key.
Next time the page is rendered, it'll use your dictionary as a cache rather than relying on Umbraco's content nodes.
Note that static variables remain intact across web requests, so they won't simply vanish when the page has rendered. Also, they're shared across all users, so you'll want to implement some locking mechanism to prevent any thread concurrency issues (e.g., two web requests attempting to modify the dictionary at the same time).
Does these persist until the end of the session then drop?
Static variables persist until the application pool shuts down. On a normal machine, this is typically defaulted to every 29 hours.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.