I've run some benchmarking of sets with ReplicateTo.ONE enabled and found very poor performance (about 300 sets/s on two six-core and 20GB ram servers).
After some research it was found that the cause is replication delay (it is about 1 second) - the code in observePoll() in java client does memcached observes every X milliseconds (could be set up upon connection establishment) and Y times.
Tuning X and Y does not affect overall performance, because actual data replication takes around 1 second (so X = 100 and Y = 10, X = 10, Y = 100 is enough, but does not improve performance).
The question is:
Is there an ability to tune replication delay in Couchbase? Why this delay is about 1 second? Is it connected to number of updates in any way?
The main goal of minimizing replication delay is to lose less document updates upon node crash. At the moment, working at 20 000 sets/s (with ReplicateTo.ZERO) leads to 20000 document updates loss if the node is crashed.
Depending of the Couchbase Server you are using you may hit the bug http://www.couchbase.com/issues/browse/MB-8453 that has been fixed in Couchbase 2.2 release.
So you do not have have a way to tune the delay of the replication on the server side. But you can configure the way the Java client is looking at the status of the replication. You can look at the parameters (
http://docs.couchbase.com/couchbase-sdk-java-1.1/#setting-runtime-parameters-for-the-couchbaseconnectionfactorybuilder . This impact the overall performance of the operation.
How do I set the obsPollInterval & obsPollMax in .NET client?