On 08/11/2016 21:49, Ahmed Musallam wrote: > Hello Dev team, Hello, someone else may correct me but here's my take
> > I am working on an AEM project where we have a large number of child nodes > that need to be created. I have a few questions around performance. > > We are using AEM 6.1 which utilizes Oak 1.2.7. > > A few questions: > > 1. I know that there is no “actual” limit to child nodes, but In your > experience, is there a limit to child nodes over which we will see > performance impact? or instability of some sort? and what would be your > recommended “virtual” number of child nodes? Depending on the node type. For oak:Unstructured I don't recall any limit off the top of my head. If you use an ordered node you may start experiencing performance degradation from about the 1k siblings. On write. But it really depends as well by the machine power and the current load. > 2. Will read/writing one node which has, lets say 10,000 sibling be > problematic for any reason? Writing of an ordered node, like nt:unstructured may be problematic. Not reading. > 3. I know that there are node types that have ordered vs unordered children. > When does Oak actually order the child nodes? on read? The order is persisted on write. When reading it simply reads a hidden property. My main concern is about maintenance of such bucket. Do you plan to manually navigate, maintain something like 10000 siblings. Have you ever tried browsing something way smaller (like 100) from the UI? Then, you may actually hit limits way earlier from the UI. For example I would say that a tree javascript UI may start having problems around the 200-500 siblings. HTH Davide
