Kafka 2.1.0压缩算法性能测试

Apache Kafka 2.1.0正式支持ZStandard —— ZStandard是Facebook开源的压缩算法,旨在提供超高的压缩比(compression ratio),具体细节参见https://facebook.github.io/zstd/。本文对Kafka支持的这几种压缩算法(GZIP、Snappy、LZ4、ZStandard)做了一下基本的性能测试,希望能够以不同维度去衡量不同压缩算法在Kafka中的表现。

一、环境准备

本次测试使用了两台云主机,一台作为Kafka的服务器,跑broker进程;另一台作为client,运行Kafka的客户端程序(producer和consumer),具体配置如下:

软件配置如下:

 二、测试topic准备

依次创建4个topic:test1、test2、test3、test4,分别用于LZ4、ZStandard、Snappy和GZIP的测试,这些topic都是单分区单副本。

三、测试producer端

使用kafka-producer-perf-test.sh脚本依次为4个topic发送60,000,000条消息,每条消息1KB大小,去计算各种压缩算法的TPS以及其他指标。结果如下:

1、客户端CPU使用率统计图

结论:Snappy算法使用的CPU资源最多,其他3种压缩算法相差不多。

2、Broker服务器带宽统计

结论:Snappy算法占用的带宽最多且遥遥领先,LZ4次之,而新引入的ZStandard使用的带宽最少。一个可能的原因是ZStandard有较高的压缩比,减少了总体的网络IO传输量。

 3、producer吞吐量(TPS)统计

 

结论:配置LZ4的producer TPS最高——LZ4算法有着最快的压缩时间(至少是top3),故整体TPS最高也不令人惊讶。Snappy次之,ZStandard位居第三位。说明ZStandard不是一个很快的压缩算法。

4、producer延时分布统计

结论:GZIP算法的延时最低,ZStandard次之。有意思的是,Snappy算法的平均值和99.9分位均值比较接近,而LZ4算法方差较大(当然也可能因为异常点导致)。总之从延时角度来看GZIP最优。

5、磁盘占用统计

 

结论:配置ZStandard算法producer生产的消息有着最高的压缩比,这符合ZStandard算法官方的定位:"Zstd can trade compression speed for stronger compression ratios." —— 即该算法牺牲一部分压缩速度去换取更高的压缩比。

四、测试consumer端 

 使用kafka-consumer-perf-test.sh脚本依次消费4个topic,每个topic消费60,000,000条消息,去计算consumer端解压缩性能以及其他核心指标,结果如下:

 1、客户端CPU使用率统计

 

结论:基本上4种压缩算法的客户端CPU使用率基本持平,ZStandard算法略高一些

2、Broker端带宽占用统计 

结论:Snappy占用带宽最多,ZStandard最少——同理,这是因为ZStandard有最高的压缩比,极大地降低了网络IO传输量。

 3、consumer吞吐量(TPS)统计

 

结论:配置LZ4算法的consumer有着最高的TPS,而ZStandard算法最低。

 五、总结

相比于其他压缩算法,ZStandard有着最高的压缩比,相同的消息量占用最少的磁盘容量,因此带宽的占用也是比较少的,但是在TPS方面的表现并不抢眼,因此对于那些在乎磁盘和带宽资源的用户而言,配置ZStandard算法似乎是个不错的选择,但如果追求应用TPS,就目前的Kafka而言LZ4依然是最好的选择。

 

posted @ 2019-01-28 18:07 huxihx 阅读(...) 评论(...) 编辑 收藏