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.

Can you please share the relevant parts of the exceptions?

Is this AEM 6.5 SP21?

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.