4 ms·

> We avoided reads (get operations) since the current version of etcd performs reads directly from the leader, without contacting the cluster, which doesn’t pre

by rystsov 10y ago

> We avoided reads (get operations) since the current version of etcd performs reads directly from the leader, without contacting the cluster, which doesn’t preserve the same consistency level as Bizur and ZooKeeper do. It's wrong. Etcd provides "?quorum=true" option which makes reads go through the Raft consensus algorithm archiving linearizability see https://github.com/coreos/etcd/issues/741 https://github.com/coreos/etcd/issues/741

ideal0227 10y ago
etcd v3 read is linearizable by default. Also I believe the authors of the paper tested against the old etcd v2 API/backend although they use etcd3. The new API/backend has significant high performance. I work on etcd.
- rystsov 10y ago
  I mean that without the ?quorum flag the stale reads are possible. I tested the etcd v3 (http api) and the reads were incredibly fast but when I set the flag, the read's latency became the same as write.
  - ideal0227 10y ago
    v3 does not have a native HTTP API. I suspect you still use v2 API. You need the gateway to make v3 works with HTTP: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/coreos/etcd/blob/master/Documentation/dev... But that might impact performance quite bit depending on your workload.
    - rystsov 10y ago
      I got it, I was using Etcd v3.1.0 but with v2 API.
- mhf8o9a 10y ago
  Bizur team member here. For etcd benchmarking we used the 'benchmark' tool from etcd's source (commit d62ce55, ~3.1.0-rc1). AFAIK that tool does use the v3 api. The paper was completed before etcd 3.1 was released. etcd's docs stated (at that time) that the client is not linearizable. We only tested writes. As for performance, it's hard to say if our results pair up with the official etcd results (we were not aware of them - were they published at the time?). The hardware & software setup used for benchmarking is different.

by rystsov 10y ago

ideal0227 10y ago

etcd v3 read is linearizable by default. Also I believe the authors of the paper tested against the old etcd v2 API/backend although they use etcd3. The new API/backend has significant high performance. I work on etcd.

rystsov 10y ago
I mean that without the ?quorum flag the stale reads are possible. I tested the etcd v3 (http api) and the reads were incredibly fast but when I set the flag, the read's latency became the same as write.
- ideal0227 10y ago
  v3 does not have a native HTTP API. I suspect you still use v2 API. You need the gateway to make v3 works with HTTP: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/coreos/etcd/blob/master/Documentation/dev... But that might impact performance quite bit depending on your workload.
  - rystsov 10y ago
    I got it, I was using Etcd v3.1.0 but with v2 API.
mhf8o9a 10y ago
Bizur team member here. For etcd benchmarking we used the 'benchmark' tool from etcd's source (commit d62ce55, ~3.1.0-rc1). AFAIK that tool does use the v3 api. The paper was completed before etcd 3.1 was released. etcd's docs stated (at that time) that the client is not linearizable. We only tested writes. As for performance, it's hard to say if our results pair up with the official etcd results (we were not aware of them - were they published at the time?). The hardware & software setup used for benchmarking is different.