E-MapReduce Kafka Benchmark - I-阿里云开发者社区

0. 测试目的

本文介绍如何利用Kafka自带的性能测试脚本测试E-MapReduce Kafka集群的性能，文末给出一份单机测试Kafka集群的性能数据。此数据仅供参考，不代表官方性能指标承诺。

非特定表述，以下所有Kafka集群指E-MapReduce Kafka集群。

1. 硬件配置

Kafka集群

节点	配置	机器数目
Master	非独享 4核16GB 80GB（高效云盘）x 1	1
Core	非独享 16核32GB 500GB（SSD云盘）x 4	10

Zookeeper集群

配置	机器数目
非独享 16核32GB 500GB（SSD 云盘）x 1	3

注意：

Kafka集群的Master节点主要用来部署一些非Kafka服务应用，例如Kafka-Manager，Zookeeper及Ganglia等等。
E-MapReduce当前未提供单独的Zookeeper集群，所以需要手动部署一套独立地Zookeeper集群。
将Kakfa集群默认的ZK指向独立部署的ZK集群。

2. 测试配置

软件版本：
- Kafka： 0.10.1.0
- Zookeeper：3.4.6
- Kafka Manager：1.3.3.7
Broker配置
- num.partitions: 100
- message.size: 1024 （默认）
- linger.ms: 0
- max.request.size: 33554432
- buffer.memory: 67108864
- min.insync.replica=2
Topic配置：
- partition数目: 100

3. 测试计划及结果

3.1 测试工具和测试方法

使用Kafka自带测试工具：

kafka-producer-perf-test.sh：测试Kafka Producer性能，主要展示发送消息数目，每秒消息发送数目（以及数据量MB），平均延迟（ms），最大延迟（ms），如下所示：

436 records sent, 86.4 records/sec (94.64 MB/sec), 333.9 ms avg latency, 617.0 max latency.
420 records sent, 83.0 records/sec (90.82 MB/sec), 365.9 ms avg latency, 814.0 max latency.
481 records sent, 93.7 records/sec (102.63 MB/sec), 315.2 ms avg latency, 579.0 max latency.
10000 records sent, 87.576410 records/sec (95.88 MB/sec), 325.37 ms avg latency, 1860.00 ms max latency, 370 ms 50th, 575 ms 95th, 779 ms 99th, 1851 ms 99.9th.

kafka-consumer-perf-test.sh：测试Kafka Consumer性能

注意：本次测试使用一台机器压测Kafka集群

3.2 固定大小消息的Produce性能

分析：
1. 随着Producer数目增加，每秒发送的消息量能够得到近似线性的性能提升。
2. 增加batch，有助于提高吞吐。batch.size=10000时，producer数目增加对吞吐影响消失，主要是由于达到了机器网卡带宽上限导致。
3. ack=-1，即提高数据可靠性的同时，会降低集群吞吐能力。所以我们需要根据实际需求在吞吐和可靠性之间做平衡
4. 随着replicas增加，吞吐率会呈现非线性的下降，这和follow和leader之间需要进行数据同步有关。同样，我们需要根据实际需求在吞吐和可靠性之间做平衡。
附acks说明：
1. acks=0: Producer不等待来自服务端同步完成的确认，继续发送下一条消息。此配置提供最弱的数据完整性保证，客户端或者服务端的异常都会导致数据丢失，且此时的客户端retries参数失效。
2. acks=1: Producer等待leader节点成功收到数据并得到确认后发送下一条消息。此配置提供更强的数据完整性保证。
3. acks=-1(all): Producer等待leader节点和follow节点都确认接收到数据后才算一次发送完成。此配置提供最强的数据完整性保证。此处的follow节点数目受限“min.insync.replicas”参数，需要配置“min.insync.replicas”使用。

3.3 不同大小消息的Produce性能

分析：
1. 消息体越大，每秒发送的消息数量越小，每秒发送的数据量(MB)也基本相应增大。部分测试case由于达到机器网卡带宽上限，所以表现的不明显。
2. 消息体越大，每次发送的有效数据量就越大，所以适当提高消息体大小，有助于提高发送效率和吞吐。

3.4 消息Consume性能

分析：
1. 单线程即可将机器网卡打满，所以增加线程数目没有带来提升

4. 碰到的问题

问题1：KafkaManager：Yikes! Ask timed out on [ActorSelection[]] after 5000 ms
- 解决方法1：kafka-manager.api-timeout-millis 调大。
- 解决方法2：修改Kafka-Manager源码，所有timeout都强行改成10s。
- 最新版Kafka Manager是否解决了这个问题，未知。

5. 后续

测试D1机型的Kafka集群性能
分布式多机压测Kafka集群