Thousends of pages under the same parent

[T_one1]

Hi,

is there any limit that tells how many pages can be placed as a direct child of the parent? Our client wants to put more than a thousand pages under the same parent. I feel like it is not a good idea but I can't find anything in docs which can confirm this. Do you have any thoughts on this based on your experiences?

[Ritesh_Mittal]

Hi @T_one1 ,

I do not think there is any limitation of child pages and I do not think there will be any performance impact or something (leaving search aside, wink) having multiple child pages. Since, the architecture is based on REST principal and every page has its own identity (URL) so we should be good. Though, the page should not have more nodes else it might have performance issue (java script, node traversing, backend logic, etc).

[Bhuwan_B · Accepted solution]

@T_one1 Please refer to below URL for clarity on your usecase:

The way a content repository is structured can impact performance as well. For best performance, the number of child nodes attached to individual nodes in a content repository should not exceed 1,000 (as a general rule).

https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/configuring-perf...

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/recommendation-on-maximum-...

https://www.netcentric.biz/insights/2019/01/not-break-aem.html

[markus_bulla_adobe]

Hi @T_one1!

I think that @Bhuwan_B already pointed you to great resources on this topic.

As stated in the performance documentation and also the linked thread in this community, there is technically no limit on the number of child nodes to a single parent. However, there is a commonly cited recommendation of a maximum of ~1.000 (or sometimes cited as 1.024) child nodes per parent.

From my experience, the part where you will first see negative effects of too many child nodes is the UI.

• First of all, if your content authors have to manage this amount of content (e. g. pages) without additional structuring, this will result in a very bad user experience for them before even coming to a point where this affects the UI or system performance.
• Even if your content authors would be fine with this drawback, you will notice performance issues in the UI (e. g. high loading times for certain views) if there are too many nodes on the same level. Even if this does not affect your regular content editors, please keep also in mind that you may have to work with the content structures through other UIs, such as CRX DE, CRX explorer or other similar.

Even the product it self takes care of organizing elements into proper structures and will automatically create an organized hierarchy for system elements, such as workflow instances, users or groups.

So my recommendation is to base the maximum number of child nodes on your use case. If you are referring to regular content authoring structures (e. g. pages, assets, c/x fragments, etc.), I would definitely recommend to keep the number to a mid 2-figure amount. If you are referring to more "technical" content that will usually not have to be managed/touched by regular users of the system but created/managed programmatically, I would still suggest to implement some kind of logic to create a content hierarchy and split the nodes into different folders with a maximum number of nodes per folder of ~ 1.000 (following the recommendation of the performance documentation).

Hope that helps!