I think that this AEM CS. This request is done by the monitoring, and therefor an internal implementation detail of AEM CS.

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?

Hi,with "secured" and "unsecured" content, are you using permission sensitive caching?

I don't think that the replication API allows you to modify content (that means: changing the values of properties and/or add/remove nodes) which is then sent only to the publish, but which is not persistet on the authoring instance.

Why do you want to use an existing service-user for code of your own? 

I think that you need to go through an intermediary step of AEM 6.5. That's because with AEM 6.4 some paths in the repository changed (for example /etc/tags moved to /content/cq:tags and some more things), which the migration tools to AEM CS don't handle.  For that reason I would recommend to go thr...

A workflow process step is a piece of code, which runs in the background. For that it is not bound to a HTTP request and also not to a user in the first place. That means that in a process step the concept of a "current user" simply does not exist.

What are you using these deploy scripts for?

Yes, maybe I should modify that log message  Thanks for reminding me. It will be fixed in one of the upcoming releases.

I have never seen the dispatcher being used as a loadbalancer, and also I am not aware of anyone using it in this role. In 2011 someone in a project of mine tested the dispatcher as loadbalancer and connected it to 6 publish instances. It distributed the requests in a very uneven way (the first publ...