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

开发者社区> 阿里云EMR> 正文
登录阅读全文

E-MapReduce Kafka Benchmark - I

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

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性能

image
image

  • 分析:

    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性能

image

  • 分析:

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

3.4 消息Consume性能

image

  • 分析:

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里巴巴开源大数据技术团队成立阿里云EMR技术圈, 每周推送前沿技术文章,直播分享经典案例、在线答疑,营造纯粹的开源大数据氛围,欢迎加入!加入钉钉群聊阿里云E-MapReduce交流2群,点击进入查看详情 https://qr.dingtalk.com/action/joingroup?code=v1,k1,cNBcqHn4TvG0iHpN3cSc1B86D1831SGMdvGu7PW+sm4=&_dt_no_comment=1&origin=11

官方博客
官网链接