Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not a Bug
-
7.1.0
-
Triaged
-
1
-
Unknown
-
KV 2021-Nov
Description
Note: Initially opened on performance variation between, that has been addressed, but now tracking the issue where replica item count does not reach active
—
In Magma insert only tests, we see high performance variation.
http://172.23.123.237/#/timeline/Linux/hidd/S0/all
In the latest runs with build 7.1.0-1558, the throughput changed from 122K to 226K.
Build | Throughput | Job |
---|---|---|
7.1.0-1558 | 122,966 | http://perf.jenkins.couchbase.com/job/rhea-5node2/1538/ |
7.1.0-1558 | 226,157 | http://perf.jenkins.couchbase.com/job/rhea-5node2/1539/ |
In the run having higher throughput, replica sync rate can't catch up.
There are more sync write flushes after a certain point.
Sarath Lakshman
Please take a look. Is there a way we can change checkpoint settings? It looks like the runs can go to different modes (or code paths), even with the same build.
Attachments
Issue Links
- relates to
-
MB-49262 Checkpoint expel stops before low mark
-
- Closed
-
Currently, our throughput tests are measuring how many client requests the cluster can handle, and I think the number is important. The same concept is applied to latency tests. We measure how fast client requests can be completed. The latency is measured when the requests are completed but not when replication is done. I agreed DCP replication performance is important, but we should measure the two things separately.
If the client request process performance is 10% slower and DCP replication performance is 20% faster, I don't think it means the overall system performance is better.
Rebalance tests are one method we use to measure DCP replication performance. If there are any ideas about how we should measure DCP replication performance, please let me know. For this particular test (insert only), another thing we can try is to do a run without replication.