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