Node reading performance

[danchapmanme]

First question:

We have a parsys used in an admin area of our site, that has over 1000 components inside. Other than browser rendering slowness, is this something that is still recommended to avoid with Oak, regarding read performance of nodes.

Node structure:

/content [sling:orderedFolder]

+ page [cq:Page]

  + page [cq:Page]

   + jcr:content [cq:PageContent]

    + parsys [nt:unstrcutured]

     + text_component [nt:unstrcutured] (x over 1000)

Second question:

On the website, we load the properties of each text_component node using adaptTo(Resource.class) instead of maybe using something like resource.valueMap(). Is there any performance gains/losses with these approaches? or would they be the same?

We are running 6.0.0.SP3 with Apache Jackrabbit Oak 1.0.34

[kautuk_sahni]

Jörg Hoh​ Need your insights here.

[Jörg_Hoh · Accepted solution]

wow, 1000 components ... this will definitly be slow, as each component include adds some overhead (mostly caused the component level filters).

The difference in performance between Sling and JCR API should be neglectable here, as the performance of this page is determined by many other factors.

Jörg

[edubey]

1000 component in the same level is huge,
Are these authored by the user or some kind of process generates it?

Do you see a way of probably splitting them into multiple pages ?

Thanks

[smacdonald2008]

1000 components on one page seems like a lot - I would take into Consideration what Praveen said - break them into multiple pages. Can you point us to a real world website that would take this many components.