AI时代已来,你准备好应对挑战了吗? 了解详情
写点什么

Pulsar 和 Kafka 基准测试报告(上)

  • 2021-01-27
  • 本文字数:4761 字

    阅读完需:约 16 分钟

Pulsar 和 Kafka 基准测试报告(上)

为了更全面地了解 Pulsar 和 Kafka,我们“复现”了 Confluent 对 Pulsar 和 Kafka 基准测试。重复这一基准测试的原因有两个,一是 Confluent 的测试方法存在一些问题;二是 Confluent 的测试范围和测试场景不够全面。为了更准确地对比 Pulsar 和 Kafka,我们在测试中不仅修复了 Confluent 测试中的问题,还扩大了测试范围,纳入更多性能衡量标准,模拟更多实际场景。


和 Confluent 的测试相比,我们的测试主要有三项改进:


  1. 包含 Pulsar 和 Kafka 支持的所有持久性级别。在同等持久性级别下,对比二者的吞吐量和延迟。

  2. 引入影响性能的其他因素和测试条件,如分区数量、订阅数量、客户端数量等。

  3. 测试的混合负载同时包含写入、追赶读和追尾读,模拟实际使用场景。


我们进行了最大吞吐量测试、发布和端到端延迟测试(具体见下篇)、追赶读测试和混合工作负载测试。由于篇幅有限,本篇主要介绍发布和端到端延迟测试详情。

最大吞吐量测试

测试目标:观测在处理发布和追尾读工作负载时 Pulsar 和 Kafka 可实现的最大吞吐量。


测试设置:通过调整分区数量,观测分区数量对吞吐量的影响。


测试策略:


  • 将所有消息都复制三次,确保容错;

  • 改变 ack 数量,测试在不同持久性保证下,Pulsar 和 Kafka 的最大吞吐量;

  • 启用 Pulsar 和 Kafka 的批处理,为不超过 10 ms 的响应延迟设置最大批处理为 1 MB 数据;

  • 改变分区数量(1、100、2000 个分区),分别测试最大吞吐量;

  • 当分区数量为 100 和 2000 时,使用 2 个 producer 和 2 个 consumer;

  • 当分区数量为 1 时,改变 producer 和 consumer 的数量,观测吞吐量变化;

  • 消息大小为 1 KB;

  • 在所有测试场景中,改变持久性级别,观测最大吞吐量。


测试结果


#1 100 个分区,1 个订阅,2 个生产者/2 个消费者


分区数量为 100,改变持久性保证,分别观测 Pulsar 和 Kafka 的最大吞吐量。在 Pulsar 和 Kafka 中,都使用 1 个订阅、2 个生产者和 2 个消费者。测试结果如下。


  • 在 1 级持久性保证(同步复制持久性,异步本地持久性)下,Pulsar 的最大吞吐量约为 300 MB/s,达到日志磁盘带宽物理极限。Kafka 的最大吞吐量约为 420 MB/s。值得注意的是,在持久性为 1 级时,Pulsar 配置一个磁盘为日志磁盘进行写入,另一个磁盘为 ledger 磁盘进行读取;而 Kafka 同时使用两个磁盘进行写入和读取。尽管 Pulsar 的设置能够提供更好的 I/O 隔离,但单个磁盘最大带宽(~300 MB/s)会限制吞吐量。

  • 将持久性(同步复制持久性和异步本地持久性)配置为 2 级时,Pulsar 和 Kafka 的最大吞吐量均可达到约 600 MB/s 。两个系统都达到了磁盘带宽的物理极限。


图 1 为 100 个分区,同步本地持久性下,Pulsar 和 Kafka 的最大吞吐量。



图 1 有 100 个分区时,Pulsar 和 Kafka 的最大吞吐量(同步本地持久性)


图 2 为 100 个分区,异步本地持久性下,Pulsar 和 Kafka 的最大吞吐量。



图 2 100 个分区时,Pulsar 和 Kafka 的最大吞吐量(异步本地持久性)


#2 2000 个分区,1 个订阅,2 个生产者/2 个消费者


分区数量从 100 增加到 2000,持久性保证不变(acks = 2),分别观测 Pulsar 和 Kafka 的最大吞吐量。在 Pulsar 和 Kafka 中,都使用 1 个订阅、两个生产者和两个消费者。测试结果如下。


  • 在 1 级持久性保证下,Pulsar 的最大吞吐量保持在约 300 MB/s,在 2 级持久性保证下则增加到约 600 MB/s;

  • 单独为每条消息刷新数据时(kafka-ack-all-sync),Kafka 的最大吞吐量从 600MB/s (100 个分区) 降到了 300MB/s 左右;

  • 使用系统默认的持久性设置(kafka-ack-all-nosync)时,Kafka 的最大吞吐量从约 500 MB/s(100 个分区)下降到约 300 MB/s。


为了了解 Kafka 吞吐量下降的原因,我们绘制了 Kafka 和 Pulsar 在每一持久性保证下的平均发布延迟图。图 3 表明,分区数量增加到 2000 时,Kafka 的平均发布延迟增加到 200 毫秒,P99 发布延迟增加到 1200 毫秒。



图 3 2000 个分区时,Pulsar 和 Kafka 的最大吞吐量


发布延迟通常会对吞吐量造成显著影响。但由于 Pulsar 客户端充分利用了 Netty 强大的异步网络框架,Pulsar 的吞吐量没有受到影响。而 Kafka 客户端使用同步实现,Kafka 的吞吐量的确受到影响。把 producer 数量增加一倍可以提高 Kafka 的吞吐量。如果生产者数量增加到 4 个,Kafka 的吞吐量能达到约 600 MB/s。


图 4:2000 个分区时,Pulsar 和 Kafka 的发布延迟



图 4 2000 个分区时,Pulsar 和 Kafka 的发布延迟


#3 1 个分区,1 个订阅,2 个生产者/2 个消费者


增加更多 broker 和分区有助于提高 Pulsar 和 Kafka 的吞吐量。为了更深入地了解这两个系统的效率,我们把分区数量设为 1,观测 Pulsar 和 Kafka 的最大吞吐量。在 Pulsar 和 Kafka 中,都使用 1 个订阅、2 个生产者和 2 个消费者。


测试结果如下:


  • 在所有持久性级别,Pulsar 的最大吞吐量都达到了约 300 MB/s;

  • 在异步复制持久性下,Kafka 的最大吞吐量达到了约 300 MB/s,但在同步复制持久性下只有约 160 MB/s。


图 5:在 1 个分区,同步本地持久性下,Pulsar 和 Kafka 的最大吞吐量



图 5 1 个分区时,Pulsar 和 Kafka 的最大吞吐量(同步本地持久性)


图 6:在 1 个分区,异步本地持久性下,Pulsar 和 Kafka 的最大吞吐量



图 6 1 个分区时,Pulsar 和 Kafka 的最大吞吐量(异步本地持久性)


#4 1 个分区,1 个订阅,1 个生产者/1 个消费者


分区数量为 1,订阅数量为 1(与上个测试相同),分别观测 Pulsar 和 Kafka 的最大吞吐量。在 Pulsar 和 Kafka 中,只使用 1 个生产者和 1 个消费者。


测试结果如下:


  • 在所有持久性级别,Pulsar 的最大吞吐量都保持在约 300 MB/s;

  • 在异步复制持久性下,Kafka 的最大吞吐量从约 300 MB/s(测试 #3 中)下降到约 230 MB/s;

  • 在同步复制持久性下,Kafka 的吞吐量从约 160 MB/s(测试 #3 中)下降到约 100 MB/s。


图 7 为在同步本地持久性,一个分区、一个生产者和一个消费者的情况下,Pulsar 和 Kafka 的最大吞吐量



图 7 一个分区、一个生产者和一个消费者时,Pulsar 和 Kafka 的最大吞吐量(同步本地持久性)


为了了解 Kafka 吞吐量下降的原因,我们绘制了 Kafka 和 Pulsar 在不同持久性保证下的平均发布延迟图(图 8)和端到端延迟图(图 9)。从下图中可以看到,即使只有一个分区,Kafka 的发布延迟和端到端延迟也从几毫秒上升到了几百毫秒。减少生产者和消费者数量会对 Kafka 吞吐量造成显著影响。相比之下,Pulsar 的延迟始终保持在几毫秒。



图 8 一个分区、一个生产者和一个消费者时,Pulsar 和 Kafka 的发布延迟(同步持久性)



图 9 一个分区、一个生产者和一个消费者时,Pulsar 和 Kafka 的端到端延迟(同步持久性)

发布和端到端延迟测试

该测试详情参见 下篇

追赶读测试

测试目标:观测在处理仅包括追赶读工作负载时 Pulsar 和 Kafka 可实现的最大吞吐量。


测试策略:


  • 将所有消息都复制三次,确保容错;

  • 改变 ack 数量,测试在不同持久性保证下,Pulsar 和 Kafka 的吞吐量变化;

  • 启用 Pulsar 和 Kafka 的批处理,为不超过 10 ms 的响应延迟设置最大批处理为 1 MB 数据;

  • 在 100 个分区的情况下,对两个系统进行基准测试;

  • 共运行四个客户端--两个生产者和两个消费者;

  • 消息大小为 1 KB。


测试一开始,生产者开始以 200K/s 的固定速率发送消息。队列中积累了 512GB 数据后,消费者开始处理数据,首先从头读取累积数据,然后在数据到达时继续处理传入数据。在测试期间,生产者持续以相同速率发送消息。


我们评估了每个系统读取 512GB 累积数据的速度,在不同持久性设置下对 Kafka 和 Pulsar 进行了比较。各项测试结果如下:


#1 启用 Pulsar 绕过 Journal 写入的异步本地持久性


本项测试中,我们在 Pulsar 和 Kafka 上使用了同等的异步本地持久性保证。我们启用了新的 Pulsar 绕过 Journal 写入,来匹配 Kafka 默认 fsync 设置中的本地持久性保证。


下图 33 给出了测试结果:


  • 只处理追赶读时,Pulsar 的最大吞吐量达到了 370 万条信息/秒(3.5 GB/s)。

  • Kafka 的最大吞吐量只达到 100 万条消息/秒(1GB/s)。

  • Pulsar 处理追赶读的速度比 Kafka 快 75%。



图 33 Pulsar 和 Kafka 的追赶读吞吐量(绕过 Journal 写入)


#2 未启用 Pulsar 绕过 Journal 写入的异步本地持久性


本项测试中,我们在 Pulsar 和 Kafka 上使用了异步本地持久性保证,但并未启用 Pulsar 绕过 Journal 写入。


下图 34 给出了测试结果:


  • 处理追赶读时,Pulsar 的最大吞吐量达到 180 万条信息/秒(1.7 GB/s)。

  • Kafka 的最大吞吐量仅达到 100 万条消息/秒(1GB/s)。

  • Pulsar 处理追赶读的速度是 Kafka 的两倍。



图 34 Pulsar 和 Kafka 的追赶读吞吐量(数据同步)


#3 同步本地持久性


本项测试中,我们在同等同步本地持久性保证下对 Kafka 和 Pulsar 进行了比较。


下图 35 给出了测试结果:


  • 只处理追赶读时,Pulsar 的最大吞吐量达到 180 万条/秒(1.7 GB/s)。

  • Kafka 的最大吞吐量只达到 100 万条消息/秒(1GB/s)。

  • Pulsar 处理追赶读的速度是 Kafka 的两倍。



图 35 Pulsar 和 Kafka 的追赶读吞吐量(无数据同步)

混合工作负载测试

测试目标:评估追赶读对混合工作负载中的发布和追尾读的影响。


测试策略:


  • 将所有消息都复制三次,确保容错;

  • 启用 Pulsar 和 Kafka 的批处理,为不超过 10 ms 的响应延迟设置最大批处理为 1 MB 数据;

  • 在 100 个分区的情况下,对两个系统进行基准测试;

  • 在不同耐久性设置下对 Kafka 和 Pulsar 进行比较;

  • 共运行四个客户端--两个生产者和两个消费者;

  • 消息大小为 1 KB;


测试一开始,两个生产者均开始以 200K/s 的固定速率发送数据,两个消费者中有一个立即开始处理追尾读。队列中积累了 512GB 数据后,另一个(追赶读)消费者开始从头读取累积数据,然后在数据到达时继续处理传入数据。在测试期间,两个生产者持续以相同的速率发布,而追尾读消费者继续以相同的速率消费数据。


测试结果如下:


#1 启用 Pulsar 绕过 Journal 写入的异步本地持久性


本项测试中,我们在同等异步本地持久性保证下对 Kafka 和 Pulsar 进行了比较。我们启用了新的 Pulsar 绕过 Journal 写入,来匹配 Kafka 默认 fsync 设置的本地持久性保证。


下图 36 显示,追赶读对 Kafka 写入造成显著影响,但对 Pulsar 影响很小。Kafka 的 P99 发布延迟增加到 1-3 秒,而 Pulsar 的延迟则稳定在几毫秒到几十毫秒间。



图 36 追赶读对 Pulsar 和 Kafka 发布延迟的影响(绕过 Journal 写入)


#2 未启用 Pulsar 绕过 Journal 写入的异步本地持久性


本项测试中,我们在 Pulsar 和 Kafka 上使用了异步本地持久性保证,但未启用 Pulsar 绕过 Journal 写入。


下图 37 显示,追赶读对 Kafka 写入造成显著影响,但对 Pulsar 影响很小。Kafka 的 P99 发布延迟增加到 2-3 秒,而 Pulsar 的延迟则稳定在几毫秒到几十毫秒之间。



图 37 追赶读对 Pulsar 和 Kafka 发布延迟的影响(数据同步)


#3 同步本地持久性


本项测试中,我们在同等同步本地持久性保证下对 Kafka 和 Pulsar 进行了比较。


下图 38 显示,追赶读对 Kafka 写入造成显著影响,但对 Pulsar 影响很小。Kafka P99 发布延迟增加到约 1.2 至 1.4 秒,而 Pulsar 的延迟则稳定在几毫秒到几十毫秒之间。



图 38 追赶读对 Pulsar 和 Kafka 发布延迟的影响(无数据同步)

结论

基于基准测试结果,我们得出以下结论:


  • 纠正配置和调优错误后,Pulsar 与 Kafka 在 Confluent 有限测试用例中实现的端到端延迟基本一致。

  • 在同等持久性保证下,Pulsar 在模拟实际应用场景的工作负载上性能优于 Kafka。

  • 以上测试中,改变了持久性保证设置、订阅、分区和客户端数量,结果表明 Pulsar 在延迟和 I/O 隔离方面均明显优于 Kafka。


原文链接:https://streamnative.io/en/blog/tech/2020-11-09-benchmark-pulsar-kafka-performance-report


相关阅读链接:https://www.infoq.cn/article/xeyeEeNNY5CG0PGyxeVD


Pulsar 用户调研:https://forms.office.com/Pages/ResponsePage.aspx?id=2zjkx2LkIkypCsNYsWmAs96ZDwmey39DhXAvi6EqbJpUNlZWQzRPMlVWNTc1WUcwUE5CWFMyUlI3QS4u

2021-01-27 19:204086

评论 1 条评论

发布
用户头像
文章翻译完不校验的吗?
2021-02-24 17:04
回复
没有更多了
发现更多内容

推荐 | 移动开发主流热更新技术

Speedoooo

小程序 APP开发 热更新

容器化 | 一文搞定镜像构建方式选型

RadonDB

MySQL Docker Kubernetes 镜像 RadonDB

【Java】:程序流程的控制

翼同学

Java 学习 编程语言 分享 8月月更

什么是知识库,为什么需要它?

Geek_da0866

点赞破百万!字节算法大佬亲撰30W字数据算法笔记:GitHub标星93K

小柴说Java

数据结构 算法 算法题 算法与数据结构 算法面试题

带你玩转“超大杯”ECS特性及实验踩坑

科技怪咖

MySql主从同步介绍

京东科技开发者

MySQL 数据库 主从同步

火热与争议并行,XDR路在何方?

极盾科技

网络安全 安全 信息安全 数据安全 xdr

极盾·析策,XDR的正确打开方式

极盾科技

网络安全 安全 数据安全 xdr

企业实践|基于软件研运一体化DevOps平台的应用解析

云智慧AIOps社区

DevOps 自动化 敏捷开发 研发管理 代码托管

对话张星亮,洞察本质,SaaS首先是一种商业模式

B Impact

兆骑科创国内外创新创业服务平台,创业大赛,企业落地孵化

兆骑科创凤阁

微信官方kbone,Web端同构的福音

Geek_99967b

小程序

什么是IP 欺骗以及如何防范?

郑州埃文科技

网络安全 IP

让GitHub炸锅的深入理解MySQL实战手册,竟出自阿里云“藏经阁”

冉然学Java

Java MySQL 高可用 阿里 构架

7 天找个 Go 工作,Gopher 要学的条件语句,循环语句 ,第3篇

梦想橡皮擦

Python 爬虫 8月月更

XSKY星辰天合与观测云完成产品兼容性互认证 构建全业务链路的可观测性

观测云

从GitHub火到了InfoQ!共计1658页的《Java岗面试核心MCA版》,拿走不谢

收到请回复

Java 程序员 金九银十 Java面试八股文 常见面试题

干货!XDR产品安全检测体系如何更好的落地?

极盾科技

网络安全 安全 信息安全 数据安全 xdr

HUAWEI内网最新发布了一份452页网络协议手册,GitHb百万收藏

小柴说Java

Java 网络协议 java程序员 TCP/IP Java工程师

Alibaba最新发布的Spring Boot项目实战文档,Github标星78k

Java面试那些事儿

Java Java 面试 java程序员 Java工程师 spring-boot

基于DevCloud进行黑白棋实时对战游戏开发实践

科技怪咖

CSDN 加入星策开源社区,携手推动企业智能化转型建设

星策开源社区

企业转型 智能化 CSDN

洞见商业新机,云原生数据库GaussDB让企业决策更科学

华为云开发者联盟

数据库 后端 华为云

直播系统源码——重视哪些功能的开发?

开源直播系统源码

软件开发 直播系统源码 直播功能

重磅发布!阿里云全链路数据湖开发治理解决方案

阿里云大数据AI技术

大数据 阿里云 数据湖 数据分析

从0到1打造推荐系统工程实战

Jay Wu

推荐系统

重磅升级!TDengine3.0正式发布

TDengine

数据库 tdengine 时序数据库

兆骑科创创新创业大赛,双创活动,赛事承办,三招三引

兆骑科创凤阁

谁在构建超云?

Kent Yao

超云

软件测试100天上岸1-测试就是找茬游戏

和牛

测试 8月月更

Pulsar 和 Kafka 基准测试报告(上)_软件工程_Geek_4a91de_InfoQ精选文章