go.etcd.io/etcd@v3.3.27+incompatible/Documentation/benchmarks/etcd-2-2-0-rc-benchmarks.md (about)

     1  ---
     2  title: Benchmarking etcd v2.2.0-rc
     3  ---
     4  
     5  ## Physical machine
     6  
     7  GCE n1-highcpu-2 machine type
     8  
     9  - 1x dedicated local SSD mounted under /var/lib/etcd
    10  - 1x dedicated slow disk for the OS
    11  - 1.8 GB memory
    12  - 2x CPUs
    13  
    14  ## etcd Cluster
    15  
    16  3 etcd 2.2.0-rc members, each runs on a single machine.
    17  
    18  Detailed versions:
    19  
    20  ```
    21  etcd Version: 2.2.0-alpha.1+git
    22  Git SHA: 59a5a7e
    23  Go Version: go1.4.2
    24  Go OS/Arch: linux/amd64
    25  ```
    26  
    27  Also, we use 3 etcd 2.1.0 alpha-stage members to form cluster to get base performance. etcd's commit head is at [c7146bd5][c7146bd5], which is the same as the one that we use in [etcd 2.1 benchmark][etcd-2.1-benchmark].
    28  
    29  ## Testing
    30  
    31  Bootstrap another machine and use the [hey HTTP benchmark tool][hey] to send requests to each etcd member. Check the [benchmark hacking guide][hack-benchmark] for detailed instructions.
    32  
    33  ## Performance
    34  
    35  ### reading one single key
    36  
    37  | key size in bytes | number of clients | target etcd server | read QPS | 90th Percentile Latency (ms) |
    38  |-------------------|-------------------|--------------------|----------|---------------|
    39  | 64                | 1                 | leader only        | 2804 (-5%) | 0.4 (+0%) |
    40  | 64                | 64                | leader only        | 17816 (+0%) | 5.7 (-6%) |
    41  | 64                | 256               | leader only        | 18667 (-6%) | 20.4 (+2%) |
    42  | 256               | 1                 | leader only        | 2181 (-15%) | 0.5 (+25%) |
    43  | 256               | 64                | leader only        | 17435 (-7%) | 6.0 (+9%) |
    44  | 256               | 256               | leader only        | 18180 (-8%) | 21.3 (+3%) |
    45  | 64                | 64                | all servers        | 46965 (-4%) | 2.1 (+0%) |
    46  | 64                | 256               | all servers        | 55286 (-6%) | 7.4 (+6%) |
    47  | 256               | 64                | all servers        | 46603 (-6%) | 2.1 (+5%) |
    48  | 256               | 256               | all servers        | 55291 (-6%) | 7.3 (+4%) |
    49  
    50  ### writing one single key
    51  
    52  | key size in bytes | number of clients | target etcd server | write QPS | 90th Percentile Latency (ms) |
    53  |-------------------|-------------------|--------------------|-----------|---------------|
    54  | 64                | 1                 | leader only        | 76 (+22%)  | 19.4 (-15%) |
    55  | 64                | 64                | leader only        | 2461 (+45%) | 31.8 (-32%) |
    56  | 64                | 256               | leader only        | 4275 (+1%) | 69.6 (-10%) |
    57  | 256               | 1                 | leader only        | 64 (+20%)  | 16.7 (-30%) |
    58  | 256               | 64                | leader only        | 2385 (+30%) | 31.5 (-19%) |
    59  | 256               | 256               | leader only        | 4353 (-3%) | 74.0 (+9%) |
    60  | 64                | 64                | all servers        | 2005 (+81%) | 49.8 (-55%) |
    61  | 64                | 256               | all servers        | 4868 (+35%) | 81.5 (-40%) |
    62  | 256               | 64                | all servers        | 1925 (+72%) | 47.7 (-59%) |
    63  | 256               | 256               | all servers        | 4975 (+36%) | 70.3 (-36%) |
    64  
    65  ### performance changes explanation
    66  
    67  - read QPS in most scenarios is decreased by 5~8%. The reason is that etcd records store metrics for each store operation. The metrics is important for monitoring and debugging, so this is acceptable.
    68  
    69  - write QPS to leader is increased by 20~30%. This is because we decouple raft main loop and entry apply loop, which avoids them blocking each other.
    70  
    71  - write QPS to all servers is increased by 30~80% because follower could receive latest commit index earlier and commit proposals faster.
    72  
    73  [hey]: https://github.com/rakyll/hey
    74  [c7146bd5]: https://github.com/coreos/etcd/commits/c7146bd5f2c73716091262edc638401bb8229144
    75  [etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks.md
    76  [hack-benchmark]: ../../hack/benchmark/