My observation is that many customers use it, but it is not officially supported by Adobe.(Also I want to point out, that the official Groovy release notes for Groovy 5.0 mention, that it was tested with Java 20. No mentioning of Java 21 or any later version.)

Why do you deploy 800 megabytes of pages and assets to your (PROD) author and publish instances? On which environment do you create the content of this package? And what was the role of the PROD authoring instance in your setup? Did you use it to create and maintain PROD content? In AEM it was alway...

while you always implement code like suggested by @narendiran100 , I would like to understand why you need to that distinction.If you need to configure different OSGI configuration for DEV and UAT (which is a DEV in AEM CS terms), you can manage them through environment variables. See https://experi...

Adobe does test its own platform, but Adobe cannot do a test of your application.

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?

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.