Limitation on the number of ops per second for Couchbase client
I study the performance of Couchbase and I noticed one interesting thing. I use JavaSDK. When adding documents in database through a single-threaded client by "set" method with parameter PersistTo.ONE number of operation per second does not exceed 5-7 ops per sec. What explains such a restriction and is there a way to increase the throughput of a single-threaded client?
When increasing the number of threads per client, the number of transactions increases. So when I create one thousand threads the number of operations per second varies from 2 to 4k
The throughput of any given operation is a function of the concurrency and the latency for that operation. If you're getting 5 to 7 operations per second, with a single thread, that means each operation is taking about 200ms. This may not be that surprising since the durability requirements are currently implemented by polling for completion of that given data mutation, and the polling interval is 100ms if I recall correctly. It can be tuned lower through the CouchbaseConnectionFactoryBuilder setObsPollInterval() method. Chances are, the latency for getting one operation to disk is somewhere between 100ms and 200ms, so it's taking two poll cycles.
Since all of the operations are batched up before writing within nodes of the cluster, you'll be able to spread that disk IO latency across many more operations by doing more work in bulk. This is is what's happening with the scenario you describe where you're doing many operations from many threads.
So, there is no limitation per-se, but the resource available in the overall deployment will limit you.
For what it's worth, I have written a cache provider that allows me to interact with Couchbase via CFML. If do a simple loop inside a single thread and put a large number of small documents into the cache without waiting for a reply, I can easily see 40k to 60k operations a second in the Couchbase console. This is all on a desktop PC of mine running a single node
Profiling your code might show you bottlenecks. I don't know if this affects it, but do you have any views based on these documents?