AEM 6.0 - Performances issues with big repositories | Community
Skip to main content
G
gregoryp3536631
Level 2
October 16, 2015
Solved

AEM 6.0 - Performances issues with big repositories

  • October 16, 2015
  • 3 replies
  • 2390 views

Hi,

I'm facing perfmances issues with an AEM 6.0 instance that have a big repository.

Some requests are taking too much time to be executed.

I've created a specific index for the requests (called flv:area)

 

01.06.2015 11:09:49.224 *WARN* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy Traversed 10000 nodes (23707 index entries) using index flv:area with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:unstructured] as a where [sling:resourceType] <> 'damit/components/metadata/document' and [damit:status] <> 'associated' and [flv:area] = 'medias' and [flv:isRush] is null and isdescendantnode(a, '/content/damx/medias') /* xpath: /jcr:root/content/damx/medias//element(*, nt:unstructured)[@sling:resourceType != 'damit/components/metadata/document' and @damit:status != 'associated' and @flv:area = 'medias' and not(@flv:isRush)] */, path=/content/damx/medias//*, property=[sling:resourceType=[is not null], flv:isRush=[is null], flv:area=[medias], damit:status=[is not null]])


01.06.2015 11:09:46.104 *DEBUG* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl xpath query: /jcr:root/content/damx/medias//element(*, nt:unstructured)[@sling:resourceType != 'damit/components/metadata/document' and @damit:status != 'associated' and @flv:area = 'medias' and not(@flv:isRush)]
01.06.2015 11:09:46.104 *DEBUG* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl xpath query creation took 0 ms
01.06.2015 11:09:49.552 *DEBUG* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl >> xpath query returned 10182 results (iterated)
01.06.2015 11:09:49.552 *DEBUG* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl consider using 'p.guessTotal' if you don't need the full total with every query
01.06.2015 11:09:49.583 *DEBUG* [0:0:0:0:0:0:0:1 [1433149786089] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl entire query execution took 3479 ms

 

As you can see with the logs, the request is taking about 3.5s which is very long...

On another instance, with the same application and an index that is more or less the same size, I didn't have any trouble as the request is executed in about 300ms. (for the same result, around 10.000 results)

The only difference between both instances is the size of the repository.

The one which is facing issues have a repository that weight 633GB. The other one weight around 12GB.

The size (633GB) is normal. The repository contains renditions for around 30.000 assets.

 

I wonder if my indexes may be "lost" in the 633GB.

It's very strange that the request is about 10 times longer on indexes that have the same size no?

 

What do you think ? Is it possible to put the indexes somewhere else than in the repository ?

 

Thanks in advance,

 

Grégory Paillard

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Lokesh_Shivalingaiah

Have you applied SP1 or SP2 ? If not please apply the same. If there still is a problem, open a ticket. 

3 replies

Lokesh_Shivalingaiah
Lokesh_ShivalingaiahAccepted solution
Level 10
October 16, 2015

Have you applied SP1 or SP2 ? If not please apply the same. If there still is a problem, open a ticket. 

G
gregoryp3536631Author
Level 2
October 16, 2015

Sorry, I forget to precise.

On both of them, I've installed the SP2 + Hotfix 6167 (Security) + Hot fix 6316 (for Oak 1.0.13).

G
gregoryp3536631Author
Level 2
October 16, 2015

For information, here are the logs from the server that is fine.

 

01.06.2015 16:47:47.228 *WARN* [0:0:0:0:0:0:0:1 [1433170066991] GET ...  HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy Traversed 10000 nodes (21962 index entries) using index flv:area with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:unstructured] as a where [sling:resourceType] <> 'damit/components/metadata/document' and [damit:status] <> 'associated' and [flv:area] = 'medias' and [flv:isRush] is null and isdescendantnode(a, '/content/damx/medias') /* xpath: /jcr:root/content/damx/medias//element(*, nt:unstructured)[@sling:resourceType != 'damit/components/metadata/document' and @damit:status != 'associated' and @flv:area = 'medias' and not(@flv:isRush)] */, path=/content/damx/medias//*, property=[sling:resourceType=[is not null], flv:isRush=[is null], flv:area=[medias], damit:status=[is not null]])

01.06.2015 16:50:10.866 *DEBUG* [0:0:0:0:0:0:0:1 [1433170210860] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl xpath query: /jcr:root/content/damx/medias//element(*, nt:unstructured)[@sling:resourceType != 'damit/components/metadata/document' and @damit:status != 'associated' and @flv:area = 'medias' and not(@flv:isRush)]
01.06.2015 16:50:10.868 *DEBUG* [0:0:0:0:0:0:0:1 [1433170210860] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl xpath query creation took 2 ms
01.06.2015 16:50:11.105 *DEBUG* [0:0:0:0:0:0:0:1 [1433170210860] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl >> xpath query returned 10021 results (iterated)
01.06.2015 16:50:11.105 *DEBUG* [0:0:0:0:0:0:0:1 [1433170210860] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl consider using 'p.guessTotal' if you don't need the full total with every query
01.06.2015 16:50:11.110 *DEBUG* [0:0:0:0:0:0:0:1 [1433170210860] GET ...  HTTP/1.1] com.day.cq.search.impl.builder.QueryImpl entire query execution took 244 ms

Terms & ConditionsAccessibility statement

Loading footer...