Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Publish Instance inaccessible during Bulk Publishing

Avatar

Community Advisor

Hello,

 

We are noticing slowness during Bulk Publishing. There are generally 100 assets at a time. Sometimes publish server is inaccessible and restores back once queue is cleared.

 

During publishing, we have 2 events 

  • Assets incoming from Author
  • Dispatcher Flush 

 

We have enabled Batch processing for Replication Agent, but no luck. Binaryless replication enabled.

 

Requesting suggestions on how we can improve this?

 

 


Aanchal Sikka

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

please run a number of threaddumps (eg. 10 dumps with 1s delay between them) on publish during such a situation, that should allow you check details.

View solution in original post

9 Replies

Avatar

Community Advisor

Hi, 

Is this happening on an On-premise instance, It is AMS? Are any useful info in the logs?



Esteban Bustamante

Avatar

Community Advisor

@EstebanBustamante 

 

This is an AMS instance. 

I have following improvements is mind, please let me know if they make sense and if there anything else we could do?

  • To use MCP based approach like Asynchronous publishing upto few assets then synchronous. 

 

ReplicationOptions options = new ReplicationOptions();
options.setSynchronous(true);
replicatorService.replicate(session, ReplicationActionType.ACTIVATE, payloadPath, options);

 

  • Using TTLs & disabling dispatcher flush agent

 

Any thing you can think of that could help with optimizing resources?


Aanchal Sikka

Avatar

Community Advisor

I think something is happening on the publisher's side. I would start by checking the JVM on the publishers, as Jorg has pointed out. You should take those dumps to see if anything is consuming memory.

Another thing I would check is indexing. Look for any unusual behavior around indexing with each activation. You should be able to see when the last indexing and re-indexing occurred and verify if everything is okay.



Esteban Bustamante

Avatar

Employee Advisor

Where does the slowness happen? On author or on publish side? And when you mention "slowness", does it only affect the respective part of the replication (sending or receiving) or does it affect the entire instance and other activities as well?

Avatar

Community Advisor

@Jörg_Hoh 

 

Thanks for the queries.

The slowness in observed on publish while accessing sites, performing search etc. Almost entire instance is slow. And it recovers in some time.


Aanchal Sikka

Avatar

Correct answer by
Employee Advisor

please run a number of threaddumps (eg. 10 dumps with 1s delay between them) on publish during such a situation, that should allow you check details.

Avatar

Community Advisor

@arunpatidar 

 

We have no control on when the data will flow to us. Many of which get published immediately. 


Aanchal Sikka

Avatar

Community Advisor

Hi @aanchal-sikka 
Not sure if you can rely on sling job and executed only few immedialty with queue.maxparallel.

If you go with it then please considering created dedicated queue[1] and thread-pool[2]

 

[1] https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html#queue... 

[2] https://sling.apache.org/documentation/bundles/apache-sling-commons-thread-pool.html#create-a-new-th... 



Arun Patidar