E-MapReduce Kafka Benchmark - I

0. 测试目的

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

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

1. 硬件配置

• Kafka集群

• Zookeeper集群

注意：

• 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集群