The replicator has a logic that if there are less than 500 items int the queue it will wait a bit (which maybe is too much) until more items shows up.
This is why the replication rate when the queue is about 600K and less is dropping.
It seems that when there are 1M items in the queue and more the replication rate is still 5-10K even if there is load on the destination.
We need to find some solution for that because that logic means that the closer the destination gets to the source, the lower the replication rate is (because there are less items on the XDCR replication queue per vbucket).
At least the good news is that the front load on the source does not have major impact on the destination.
Damien is looking at the code in question: I don't see the where the batch size would cause this slowdown. I believe this is a problem in ep-engine where it gets into a state where waking the flusher doesn't work for some reason, so it it must wait for it wake itself.
I'm going to add some code to see how long we wait for full commits to happen, vs how long we spend doing the other replication work.
|For Gerrit Dashboard: &For+MB-6586=message:MB-6586|
|20894,7||MB-6586: make XDCR checkpoint interval fixed and configurable||ns_server||Status: ABANDONED||0||0|