etcd性能及評測方法

理解性能

    etcd 提供穩定的,持續的高性能。兩個定義性能的因素:延遲(latency)和吞吐量(throughput)。延遲是完成操作的時間。吞吐量是在某個時間期間之內完成操作的總數量。當 etcd 接收併發客戶端請求時,通常平均延遲隨着總體吞吐量增加而增加。在通常的雲環境,比如 Google Compute Engine (GCE) 標準的 n-4 或者 AWS 上相當的機器類型,一個三成員 etcd 集羣在輕負載下可以在低於1毫秒內完成一個請求,並在重負載下可以每秒完成超過 30000 個請求。

    etcd 使用 Raft 一致性算法來在成員之間複製請求並達成一致。一致性性能,特別是提交延遲,受限於兩個物理約束:網絡IO延遲和磁盤IO延遲。完成一個etcd請求的最小時間是成員之間的網絡往返時延(Round Trip Time / RTT),加需要提交數據到持久化存儲的 fdatasync 時間。在一個數據中心內的 RTT 可能有數百毫秒。在美國典型的 RTT 是大概 50ms, 而在大陸之間可以慢到400ms. 旋轉硬盤(注:指傳統機械硬盤)的典型 fdatasync 延遲是大概 10ms。對於 SSD 硬盤, 延遲通常低於 1ms. 爲了提高吞吐量, etcd 將多個請求打包在一起並提交給 Raft。這個批量策略讓 etcd 在重負載試獲得高吞吐量.

    有其他子系統影響到 etcd 的整體性能。每個序列化的 etcd 請求必須通過 etcd 的 boltdb支持的(boltdb-backed) MVCC 存儲引擎,它通常需要10微秒來完成。etcd 定期遞增快照它最近實施的請求,將他們和之前在磁盤上的快照合併。這個過程可能導致延遲尖峯(latency spike)。雖然在SSD上這通常不是問題,在HDD上它可能加倍可觀察到的延遲。而且,進行中的壓縮可以影響 etcd 的性能。幸運的是,壓縮通常無足輕重,因爲壓縮是錯開的,因此它不和常規請求競爭資源。RPC 系統,gRPC,爲 etcd 提供定義良好,可擴展的 API,但是它也引入了額外的延遲,尤其是本地讀取。

評測

    可以通過 etcd 自帶的 benchmark CLI 工具來評測 etcd 的性能.

3節點硬件配置

  • Google Cloud Compute Engine

  • 3 machines of 8 vCPUs + 16GB Memory + 50GB SSD

  • 1 machine(client) of 16 vCPUs + 30GB Memory + 50GB SSD

  • Ubuntu 17.04

  • etcd 3.2.0, go 1.8.3

使用這些配置,etcd 能近似的寫入:

key的數量

Key的大小

Value的大小

連接數量

客戶端數量

目標 etcd 服務器

平均寫入 QPS

每請求平均延遲

內存

10,000

8

256

1

1

leader only

583

1.6ms

48 MB

100,000

8

256

100

1000

leader only

44,341

22ms

124MB

100,000

8

256

100

1000

all members

50,104

20ms

126MB

示例命令:

# 寫向leader

benchmark --endpoints=${HOST_1} --target-leader --conns=1 --clients=1 \

    put --key-size=8 --sequential-keys --total=10000 --val-size=256 

benchmark --endpoints=${HOST_1} --target-leader  --conns=100 --clients=1000 \

    put --key-size=8 --sequential-keys --total=100000 --val-size=256

# 寫向所有成員

benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \

    put --key-size=8 --sequential-keys --total=100000 --val-size=256

    爲了一致性,線性化(Linearizable)讀取請求要通過集羣成員的法定人數來獲取最新的數據。串行化(Serializable)讀取請求比線性化讀取要廉價一些,因爲他們是通過任意單臺 etcd 服務器來提供服務,而不是成員的法定人數,代價是可能提供過期數據。etcd 可以讀取:

請求數量

Key 大小

Value 大小

連接數量

客戶端數量

一致性

每請求平均延遲

平均讀取 QPS

10,000

8

256

1

1

Linearizable

1,353

0.7ms

10,000

8

256

1

1

Serializable

2,909

0.3ms

100,000

8

256

100

1000

Linearizable

141,578

5.5ms

100,000

8

256

100

1000

Serializable

185,758

2.2ms

示例命令:

# 單客戶端讀benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \

    range YOUR_KEY --consistency=l --total=10000 

benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \

    range YOUR_KEY --consistency=s --total=10000

# 多客戶端併發讀

benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \

    range YOUR_KEY --consistency=l --total=100000 

benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \

    range YOUR_KEY --consistency=s --total=100000

當在新的環境中第一次搭建 etcd 集羣時,我們鼓勵運行評測測試來保證集羣達到足夠的性能;集羣延遲和吞吐量對微小的環境差異會很敏感。


官網原文地址:https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md

參考翻譯文章:https://skyao.gitbooks.io/learning-etcd3/content/documentation/op-guide/performance.html


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章