Kafka 2.1.0壓縮算法性能測試

Apache Kafka 2.1.0正式支持ZStandard —— ZStandard是Facebook開源的壓縮算法，旨在提供超高的壓縮比(compression ratio)，具體細節參見https://facebook.github.io/zstd/。本文對Kafka支持的這幾種壓縮算法(GZIP、Snappy、LZ四、ZStandard)作了一下基本的性能測試，但願可以以不一樣維度去衡量不一樣壓縮算法在Kafka中的表現。

1、環境準備

本次測試使用了兩臺雲主機，一臺做爲Kafka的服務器，跑broker進程；另外一臺做爲client，運行Kafka的客戶端程序(producer和consumer)，具體配置以下：

軟件配置以下：

 2、測試topic準備

依次建立4個topic：test一、test二、test三、test4，分別用於LZ四、ZStandard、Snappy和GZIP的測試，這些topic都是單分區單副本。

3、測試producer端

使用kafka-producer-perf-test.sh腳本依次爲4個topic發送60,000,000條消息，每條消息1KB大小，去計算各類壓縮算法的TPS以及其餘指標。結果以下：

一、客戶端CPU使用率統計圖

結論：Snappy算法使用的CPU資源最多，其餘3種壓縮算法相差很少。

二、Broker服務器帶寬統計

結論：Snappy算法佔用的帶寬最多且遙遙領先，LZ4次之，而新引入的ZStandard使用的帶寬最少。一個可能的緣由是ZStandard有較高的壓縮比，減小了整體的網絡IO傳輸量。

 三、producer吞吐量(TPS)統計

 

結論：配置LZ4的producer TPS最高——LZ4算法有着最快的壓縮時間（至少是top3），故總體TPS最高也不使人驚訝。Snappy次之，ZStandard位居第三位。說明ZStandard不是一個很快的壓縮算法。

四、producer延時分佈統計

結論：GZIP算法的延時最低，ZStandard次之。有意思的是，Snappy算法的平均值和99.9分位均值比較接近，而LZ4算法方差較大（固然也可能由於異常點致使）。總之從延時角度來看GZIP最優。

五、磁盤佔用統計

 

結論：配置ZStandard算法producer生產的消息有着最高的壓縮比，這符合ZStandard算法官方的定位："Zstd can trade compression speed for stronger compression ratios." —— 即該算法犧牲一部分壓縮速度去換取更高的壓縮比。

4、測試consumer端 

 使用kafka-consumer-perf-test.sh腳本依次消費4個topic，每一個topic消費60,000,000條消息，去計算consumer端解壓縮性能以及其餘核心指標，結果以下：

 一、客戶端CPU使用率統計

 

結論：基本上4種壓縮算法的客戶端CPU使用率基本持平，ZStandard算法略高一些

二、Broker端帶寬佔用統計 

結論：Snappy佔用帶寬最多，ZStandard最少——同理，這是由於ZStandard有最高的壓縮比，極大地下降了網絡IO傳輸量。

 三、consumer吞吐量(TPS)統計

 

結論：配置LZ4算法的consumer有着最高的TPS，而ZStandard算法最低。

 5、總結

相比於其餘壓縮算法，ZStandard有着最高的壓縮比，相同的消息量佔用最少的磁盤容量，所以帶寬的佔用也是比較少的，可是在TPS方面的表現並不搶眼，所以對於那些在意磁盤和帶寬資源的用戶而言，配置ZStandard算法彷佛是個不錯的選擇，但若是追求應用TPS，就目前的Kafka而言LZ4依然是最好的選擇。