Performance related query regarding oak:index aggrigates.

[Prakash_Ganipi]

Hello team, 

We are performing a full-text search query on /content/mysite that returns results for all pages (cq:Page) containing the specified search term within their properties. The query functions correctly for child nodes up to level 4 for any given page. However, it fails to retrieve search terms from nodes located deeper than level 4 under the jcr:content node.

For instance, I identified a text component at /content/mysite/us/en/home/test-page/jcr:content/bootstrap-template/container/bootstrap_grid/bs-container-0/bootstrap_grid_889394484/bs-container-0/text_1226911357_copy (this component is at level 7 after jcr:content). I updated the text property with the term “testingtheindexes”. When I executed a full-text query for this term using the query builder, it returned 0 results. At the same time, running the same query for a component at level 3 after jcr:content yielded the expected result.

Upon further investigation, we discovered that the include aggregate configurations at /oak:index/cqPageLucene determine the depth of nodes included in the index. By default, the configurations are set to *, */*, */*/*, */*/*/*. We added a custom configuration */*/*/*/*/*/* to include nodes up to 7 levels deep after jcr:content. Following this adjustment, the query from the above example began returning the expected results.

I would like to understand if there is any recommended limits or thresholds for the depth of child nodes included in the index configuration since we have identified some instances in our content where the components that go as deep as level 14 (could be one's that goes even deeper too). Our goal is to ensure optimal performance without affecting system efficiency.

If any of you came across similar issue and have implemented a solution, I would really appreciate if you could share your experience. 

Please let me know if you have any questions.

[Kamal_Kishor]

@Prakash_Ganipi : Can you please share your sample query? It will be easier for someone to see what could be the issue there.

If you are using "type=cq:Page" in your fulltext query, by default it will only search for content on the jcr:content node of your pages, so anything beneath that is not searched. Just for your testing you can try removing this condition in querybuilder and see if it works for you. You can try updating your query.

[Prakash_Ganipi]

@Kamal_Kishor Thank you for your response. Yes, I did try the query without  using "type=cq:Page" but that didn't work. Below is our sample query that I ran using the query builder debugger API,

type=cq:Page
path=/content/mysite/en
fulltext=keyword

That being said, we raised a support case with Adobe and here is what they have recommended,

Is it safe to include any number of includes in cqPageLucene aggregates (with no limitations)?
Response: Yes it should be safe to increase this within reason - for example 20 levels should be fine.