It’s great to work in a company like Sitecore. I’ve seen a lot of countries so far and this weekend I’m again in the beautiful and quite city of Copenhagen. Travelling, meeting people and a lot of thinking; guess that’s the story of my first few months being part of Sitecore International. I might forgot about the talking. I’ve been talking even more then travelling, although for those who know me, that is definitely not a problem.
And last but not least, I’ve been participating. Participating in great internal discussions. These days for example, I had a great time spending on geek and non-geek talks with Phil(Australia), Henrik, Jakob, Ole, Jesper and Lars.
A couple of weeks ago question by one of our partner managers came into my mailbox. Because of being on the road, I couldn’t find time to react. Luckily the mail was also sent to our friends of the Denmark office who where so kind to react in the a very valuable way.
Does the amount of nodes in the content tree affect the performance?
Please read these two answers and learn:
If we are talking 100,000s of items – probably yes 🙂
Also there’s the thumb rule regarding items on the same level – that is “siblings”. Here you don’t want more than 100 – max 200 (that also goes for media library of course) – but that’s a question of architecture – not capacity 🙂
When you look at the above answer you probably think there isn’t a better answer. This is so not true, Frank McDonald spent a little more time on his reaction to Kim:
The subject is here not how many items but what is the architecture in question! How many users, using what interfaces, and the complexity of the solution, and the expected response time. What other solutions are running on the network / servers.
If the expectation is for high performance then you better have a high performance system to service requests.
Theoretical limit of items is around 1 million. More than 100 items in any node will require (generally) special consideration to architecture. Concurrent editors ‘compete’ with concurrent users, and more complex solutions require more complex infrastructure.
Use the same theoretical analysis for back-end as you use in front end (from tech white paper) and you’ll be better off.
Frank’s last sentence is maybe the best guideline. You will never present more then 100 items on 1 single page. So why do you want to combine them in one folder?
Then the theoretical limit, this has all to do with the way we calculate items. We know the average size of items, figure out what’s the maximum amount of memory your system is allowed to use(32-bit architecture, just 3,6 Gb!!), figure out how much can be claimed by the hosting App(IIS), take the limitations your cache system has and subtract those figures. But again, Frank’s guideline is legal again. Who the hell will have more then 1 million items in 1 database?
Don’t become afraid of big figures when it comes to items and also do not use these figures as a definitive maximum. We’ve managed to create pretty quick solutions with over 2 million items in a database.
Meanwhile Sitecore is scaling up as well. Upcoming releases are better optimised and will have more advanced data structures for handling larger amounts of items. I’m not sure we’ll reach 1 billion items within a year, but I’m sure it’s feasible within 3 years. When you look at the way hardware is scaling these days, I’m sure our core-team can do that as well.
Although I’m not sure any content editor is able to get an overview of 1 million items. Consider a news folder with 100.000 news items. They are divided by year and then by month. And this is the second year they are using the system. Then you definitely have to reconsider together with the customer what’s the value of these items and think about solutions like external database, etc.
I was amazed by the number of one million, but it feels a bit limited as well. I personally think Sitecore has a lot of abilities to scale if you reach those limitations (and again normally they aren’t, your architecture is). I’d also love to think with you about a proper solution :).
In this case: happy solution designing!