Expand my Community achievements bar.

SOLVED

AEM6 and DAM workflows are very slow

Avatar

Level 2

Hi.

 

I have a problem with DAM assets. They are fired every time when package is deployed to author instance. After deployment, CQ generates rendition, which takes about 3-10minutes. In that time author instance is almost unuseable (pages loads very, very long)

 

I have aem 6 instance without any hotfixes and using mongoMK.

From time to time, after deployment of my project renditions are generated only for one asset, and also there is an exception in logs:

Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /path/to/jpg/jcr:content

1 Accepted Solution

Avatar

Correct answer by
Level 10

Andrew Pikjty wrote...

Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.

I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.

I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.

I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..

 

Look at Logs, thread dump, profiler output at time of performance will help.

View solution in original post

4 Replies

Avatar

Level 10

Your query is for performance Or error after Writeback turnoff?

Avatar

Level 2

Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.

I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.

I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.

I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..

Avatar

Correct answer by
Level 10

Andrew Pikjty wrote...

Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.

I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.

I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.

I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..

 

Look at Logs, thread dump, profiler output at time of performance will help.

Avatar

Level 2

Nothing special there, logs are clear, there is just information that for some on assets some steps are skipped, but this is normal. A lot of assets are generated after each deploy. 

Profiler Results Packages: 33%: com.* 32%: com.scene7.* 32%: com.scene7.is.* 32%: com.scene7.is.scalautil.* 32%: com.scene7.is.scalautil.service 50%: org.* 48%: org.eclipse.* 48%: org.eclipse.jetty.* 32%: org.eclipse.jetty.io.* 32%: org.eclipse.jetty.io.nio 16%: org.eclipse.jetty.server.* 16%: org.eclipse.jetty.server.nio Top 20 stack trace(s) of 399432 ms 

this is te profiler results