4

I always understood that Sitecore recommends having fewer than 100 items under a node.

Is this rule still valid?

Does having too many child items only impact the Content Editor when opening the node to show children, or does it also have a performance impact for the Sitecore API as well?

FYI I'm at the point where we have 200 - 300 child items and trying to decide whether its worth refactoring things. These items are commerce catalogue items if that makes any difference.

6

It's still a good rule of thumb, even if there was no technical reason for it then at least from a UX perspective. Having a large number of items makes it more difficult for authors to be able to find the item in the tree. If the authors never need to directly edit these items, this may be less of a concern.

Sitecore itself will not care how many items you create in a content node. There is no hard limit as far as I know, and it could handle it.

There are technical reasons for limiting it to 100 items. The Query.MaxItems is set to 100 by default.

<!--  Query.MaxItems
        Specifies the max number of items in a query result set.
        If the number is 0, all items are returned. This may affect system performance, if a
        large query result is returned.
        This also controls the number of items in Lookup, Multilist and Valuelookup fields.
        Default value: 100
  -->
<setting name="Query.MaxItems" value="100" />

This setting was changed to 260 for a while in Sitecore 8.1+, but I note it is back to the 100 value in Sitecore 9+.

This will affect any XPath queries that your code may be using, both in the site code as well as Source for fields. It can be argued that you should be using ContentSearch for site where possible possible, be aware of the limitation, but OOTB this is not possible for a DropLink field for example.

You also have to take performance into consideration. Having a large content tree section (or increasing the above) will result in larger loads on your SQL Server particularly to return larger result sets. For your CD instances, you can rely more heavily on caches for this to be less of an issue. You will have to check performance on a real life instance - what may run fine on your local machine with a single user behaves very differently on a production instance with 50 content authors.

Browser performance is probably less of a concern in this modern age, but when the 100 item recommendation was first made, browsers would start to choke with large numbers of DOM elements. I don't believe this is as much of a concern with modern browsers.

Depending on your code and your exact needs, a 200-300 items in the tree may not be too much of an issue with modern hardware, but I would highly recommend considering a refactor at anything larger.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.