AI 助理
备案控制台
开发者社区 物联网 文章 正文

性能工具之emqtt-bench BenchMark 测试示例

2024-04-21 536
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 【4月更文挑战第19天】在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测，本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试，让大家对 MQTT消息中间 BenchMark 测试有个整体了解，方便平常在压测工作查阅。

一、前言

在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测，本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试，让大家对 MQTT消息中间 BenchMark 测试有个整体了解，方便平常在压测工作查阅。

BenchMark 测试以 MQTT 最典型的场景来验证其性能：

  • 并发连接：使用 emqtt-bench 创建海量连接到 MQTT Broker。
  • 消息吞吐量测试：使用 emqtt-bench 在 EMQX 中创建出海量的 Qos0 消息吞吐量，分别模拟发布-订阅 1对1，1对多，多对1这 3 种类型场景。

三、机器准备

共需准备六台服务器，一台为 EMQX Broker，七台为客户端压力机。其中：

EMQX Broker（1台）：

  • 系统：CentOS Linux release 7.6.1810 (Core)
  • CPU：8C
  • 内存：8GB
  • 服务端：EMQX 5.1.6
  • 压力机：emqtt-bench-0.4.18-el7-amd64.tar.gz

压力机（6台）：

  • 系统：CentOS Linux release 7.6.1810 (Core)
  • CPU：8C
  • 内存：16GB
  • 压力机：emqtt-bench-0.4.18-el7-amd64.tar.gz

四、典型压测场景

1、并发连接

  • 场景名称：MQTT Broker 单节点支持 30 万级设备在线，背景连接 (只连接不发送消息)
  • 描述：模拟 30 万 MQTT TCP 并发连接，并保持在线，测试执行 1 个小时。
  • 期望结果：内网测试成功率为 100%，无连接掉线，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

拓扑结构如下：
image.png

在6台客户端压力机上同时执行该命令，在每台压力机上启动 5w 的连接数，共计 30w 的连接：

./emqtt_bench conn -h emqx-server -c 50000

客户端压力机执行截图：
image.png

EMQX Broker运行情况：
image.png

在 MQTT Broker 单节点 8C8G的情况，我压到的峰值是30W连接，超过会导致服务崩溃。

2、消息吞吐量测试

注意这里我只具体说明如何设置，并不是实际压测场景数据。

2.1 1 对 1（示例）

  • 场景名称：MQTT Broker 单节点 500 并发连接下支持1000 QoS0 消息吞吐
  • 描述：1000 MQTT TCP 连接， pub 客户端和 sub 客户端数量相同都是 500，每个接收端均订阅一个对应的发送端 pub 主题，每个 pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节（默认值）的消息。因此消息发送和接收均为每秒 1000，总的消息吞吐达到每秒 2000。测试执行 1 个小时。
  • 期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

拓扑结构如下：

image.png

单台sub 客户端压力机：

./emqtt_bench sub -t test_topic_%i -h emqx-server -c 500

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
[root@ bin]# ./emqtt_bench sub -t test_topic_%i -h emqx-server -c 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=104 rate=103.28/sec
1s connect_succ total=104 rate=103.28/sec
2s sub total=200 rate=96.00/sec
2s connect_succ total=200 rate=96.00/sec
3s sub total=296 rate=96.00/sec
3s connect_succ total=296 rate=96.00/sec
4s sub total=400 rate=104.00/sec
4s connect_succ total=400 rate=104.00/sec
5s sub total=496 rate=96.00/sec
5s connect_succ total=496 rate=96.00/sec
6s sub total=500 rate=4.00/sec
6s connect_succ total=500 rate=4.00/sec

单台 pub 客户端压力机：

./emqtt_bench pub -t test_topic/%i -h  emqx-server -c 500 -I 500

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
  • -I：每间隔多少时间创建一个客户端；单位：毫秒
[root@ bin]# ./emqtt_bench pub -t test_topic/%i -h  emqx-server -c 500 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=160 rate=159.05/sec
1s connect_succ total=104 rate=103.38/sec
2s pub total=512 rate=352.00/sec
2s connect_succ total=200 rate=96.00/sec
3s pub total=1056 rate=544.00/sec
3s connect_succ total=296 rate=96.00/sec
4s pub total=1808 rate=752.00/sec
4s connect_succ total=400 rate=104.00/sec
5s pub total=2752 rate=944.00/sec
5s connect_succ total=496 rate=96.00/sec
6s pub total=3752 rate=1000.00/sec
6s connect_succ total=500 rate=4.00/sec
7s pub total=4752 rate=1000.00/sec
8s pub total=5752 rate=1000.00/sec
9s pub total=6752 rate=1000.00/sec
10s pub total=7752 rate=1000.00/sec
11s pub total=8752 rate=1000.00/sec
12s pub total=9752 rate=1000.00/sec
13s pub total=10752 rate=1000.00/sec
14s pub total=11752 rate=1000.00/sec

在订阅客户端压力机，可看到当前接收消息的速率，类似于：

12s pub total=9752 rate=1000.00/sec

MQTT Broker 运行情况：
image.png

2.2 多对1（示例）

  • 场景名称：并发连接+消息吞吐（上报）
  • 描述：501 MQTT TCP 连接， pub 客户端 500 和 sub 客户端1，接收端均订阅同一个主题，每个 pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节的消息。因此消息发送和接受均为每秒 1000，总的消息吞吐达到每秒 2000。测试执行 1 个小时。
  • 期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

拓扑结构如下：
在这里插入图片描述

单台 sub 客户端压力机：

./emqtt_bench sub -t test_topic -h emqx-server -c 1

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
[root@ bin]# ./emqtt_bench sub -t test_topic -h emqx-server -c 1
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=1 rate=0.99/sec
1s connect_succ total=1 rate=0.99/sec

单台 pub 客户端压力机：

./emqtt_bench pub -t test_topic -h  emqx-server -c 500 -I 500

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
  • -I：每间隔多少时间创建一个客户端；单位：毫秒
root@bin]# ./emqtt_bench pub -t test_topic -h  emqx-server -c 500 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=160 rate=158.89/sec
1s connect_succ total=104 rate=103.28/sec
2s pub total=496 rate=336.00/sec
2s connect_succ total=184 rate=80.00/sec
3s pub total=1040 rate=544.00/sec
3s connect_succ total=296 rate=112.00/sec
4s pub total=1792 rate=752.00/sec
4s connect_succ total=400 rate=104.00/sec
5s pub total=2736 rate=944.00/sec
5s connect_succ total=496 rate=96.00/sec
6s pub total=3736 rate=1000.00/sec
6s connect_succ total=500 rate=4.00/sec
7s pub total=4736 rate=1000.00/sec
8s pub total=5736 rate=1000.00/sec
9s pub total=6736 rate=1000.00/sec
10s pub total=7736 rate=1000.00/sec
11s pub total=8736 rate=1000.00/sec
12s pub total=9736 rate=1000.00/sec
13s pub total=10736 rate=1000.00/sec
14s pub total=11736 rate=1000.00/sec
15s pub total=12736 rate=1000.00/sec
16s pub total=13736 rate=1000.00/sec
17s pub total=14736 rate=1000.00/sec

MQTT Broker 运行情况（举例）：
image.png

2.3 1对多（示例）

  • 场景名称：消息广播
  • 描述：501 MQTT TCP 连接， pub 客户端 1 和 sub 客户端 500，接收端均订阅同一个主题，pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节的消息。因此消息发送为每秒 2，消息接收为每秒 1000，总的消息吞吐达到每秒 1002。测试执行 1 个小时。
  • 期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

拓扑结构如下：
image.png

单台 sub 客户端压力机：

./emqtt_bench sub -t test_topic -h emqx-server -c 500

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
[root@d bin]# ./emqtt_bench sub -t test_topic -h emqx-server -c 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=104 rate=103.38/sec
1s connect_succ total=104 rate=103.38/sec
2s sub total=200 rate=96.00/sec
2s connect_succ total=200 rate=96.00/sec
3s sub total=296 rate=96.00/sec
3s connect_succ total=296 rate=96.00/sec
4s sub total=400 rate=104.00/sec
4s connect_succ total=400 rate=104.00/sec
5s sub total=496 rate=96.00/sec
5s connect_succ total=496 rate=96.00/sec
6s sub total=500 rate=4.00/sec
6s connect_succ total=500 rate=4.00/sec

单台 pub 客户端压力机：

./emqtt_bench pub -t test_topic -h  emqx-server -c 1 -I 500

参数说明：

  • -s：消息 Payload 的大小；单位：字节。不加默认256字节。
  • -t：topic，%i：表示客户端的序列数
  • -h：要连接的 MQTT 服务器地址
  • -c：客户端总数
  • -I：每间隔多少时间创建一个客户端；单位：毫秒
[root@ bin]# ./emqtt_bench pub -t test_topic -h  emqx-server -c 1 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=2 rate=1.99/sec
1s connect_succ total=1 rate=0.99/sec
2s pub total=4 rate=2.00/sec
3s pub total=6 rate=2.00/sec
4s pub total=8 rate=2.00/sec
5s pub total=10 rate=2.00/sec
6s pub total=12 rate=2.00/sec
7s pub total=14 rate=2.00/sec
8s pub total=16 rate=2.00/sec
9s pub total=18 rate=2.00/sec
10s pub total=20 rate=2.00/sec
11s pub total=22 rate=2.00/sec
12s pub total=24 rate=2.00/sec
13s pub total=26 rate=2.00/sec
14s pub total=28 rate=2.00/sec
15s pub total=30 rate=2.00/sec
16s pub total=32 rate=2.00/sec
17s pub total=34 rate=2.00/sec

EMQX Broker 运行情况（举例）：
image.png

五、遇到的问题

client(): EXIT for {shutdown,eaddrnotavail}

在压力机连接超过5万的时候，出现了emqtt_bench客户端报错的情况。

EMQX Broker 运行情况：

image.png

单台客户端压力机报错截图：
image.png

通过设置以下内核参数解决：

#允许当前会话 / 进程打开文件句柄数:
ulimit -n 1048576

# 可用端口范围:
sudo sysctl -w net.ipv4.ip_local_port_range="1025 65534"

原因分析：
Linux 内核在这个范围内选择一个可用的端口作为本地端口去connect服务器，如果没有可用的端口可用，比如这个范围内的端口都处于如下状态中的一种：

  1. bind使用的端口
  2. 端口处于非TIME_WAIT状态
  3. 端口处于TIME_WAIT状态，但是没有启用tcp_tw_reuse，那么就会返回EADDRNOTAVAIL错误。

一般情况下，出现这个错误可用使用如下方法解决问题：

  1. 增大可选端口的范围，修改/proc/sys/net/ipv4/ip_local_port_range的值。
  2. 开启tcp_tw_reuse，允许使用TIME_WAIT状态的端口。

六、附录：调优建议

当然，我们也可以在 Beachmark 测试前就做好服务器参数调优，可以参考以下的内容。

1、关闭交换分区

Linux 交换分区可能会导致 EMQX Broker 出现不确定的内存延迟，影响系统的稳定性。 建议永久关闭交换分区。

  • 要立即关闭交换分区，执行命令 sudo swapoff -a。
  • 要永久关闭交换分区，在 /etc/fstab 文件中注释掉 swap 行，然后重新启动主机。

2、Linux 操作系统参数

系统全局允许分配的最大文件句柄数:

sysctl -w fs.file-max=2097152
sysctl -w fs.nr_open=2097152
echo 2097152 > /proc/sys/fs/nr_open

允许当前会话 / 进程打开文件句柄数:

ulimit -n 1048576

/etc/sysctl.conf

持久化 fs.file-max 设置到 /etc/sysctl.conf 文件:

fs.file-max = 1048576

/etc/systemd/system.conf 设置服务最大文件句柄数:

DefaultLimitNOFILE=1048576

/etc/security/limits.conf

/etc/security/limits.conf 持久化设置允许用户 / 进程打开文件句柄数:

*      soft   nofile      1048576
*      hard   nofile      1048576

3、TCP 协议栈网络参数

并发连接 backlog 设置:

sysctl -w net.core.somaxconn=32768
sysctl -w net.ipv4.tcp_max_syn_backlog=16384
sysctl -w net.core.netdev_max_backlog=16384

可用端口范围:

sysctl -w net.ipv4.ip_local_port_range='1024 65535'

TCP Socket 读写 Buffer 设置:

sysctl -w net.core.rmem_default=262144
sysctl -w net.core.wmem_default=262144
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.core.optmem_max=16777216

sysctl -w net.ipv4.tcp_rmem='1024 4096 16777216'
sysctl -w net.ipv4.tcp_wmem='1024 4096 16777216'

TCP 连接追踪设置:

sysctl -w net.nf_conntrack_max=1000000
sysctl -w net.netfilter.nf_conntrack_max=1000000
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

TIME-WAIT Socket 最大数量、回收与重用设置:

sysctl -w net.ipv4.tcp_max_tw_buckets=1048576

# 注意：不建议开启該设置，NAT 模式下可能引起连接 RST
# sysctl -w net.ipv4.tcp_tw_recycle=1
# sysctl -w net.ipv4.tcp_tw_reuse=1

FIN-WAIT-2 Socket 超时设置:

sysctl -w net.ipv4.tcp_fin_timeout=15

3、测试客户端设置

测试客户端服务器在一个接口上，最多只能创建 65000 连接:

# 可用端口范围:
sysctl -w net.ipv4.ip_local_port_range="500 65535"

#允许当前会话 / 进程打开文件句柄数:
echo 1048576 > /proc/sys/fs/nr_open
ulimit -n 1048576

参考资料：

文章标签：
云消息队列 MQ
性能测试
测试技术
Linux
网络协议
网络性能优化
安全
关键词：
测试工具
测试性能
性能测试
工具测试
benchmark测试
相关实践学习
消息队列RocketMQ版：基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能，涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列：消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验：基于MNS，0基础轻松构建 Web Client 本节课带您一起基于MNS，0基础轻松构建 Web Client
zuozewei
目录
相关文章
jsjsjjs
|
15天前
|
数据采集 监控 机器人
浅谈网页端IM技术及相关测试方法实践（包括WebSocket性能测试）
最开始转转的客服系统体系如IM、工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务，以及客服的效率等都产生了诸多限制，所以我们决定自研替换第三方系统。下面主要分享一下网页端IM技术及相关测试方法，我们先从了解IM系统和WebSocket开始。
jsjsjjs
33 4
请看我回答~
|
18天前
|
Java 测试技术 数据安全/隐私保护
软件测试中的自动化策略与工具应用
在软件开发的快速迭代中，自动化测试以其高效、稳定的特点成为了质量保证的重要手段。本文将深入探讨自动化测试的核心概念、常见工具的应用，以及如何设计有效的自动化测试策略，旨在为读者提供一套完整的自动化测试解决方案，帮助团队提升测试效率和软件质量。
请看我回答~
34 3
恩爸编程
|
11天前
|
Web App开发 IDE 测试技术
Selenium：强大的 Web 自动化测试工具
Selenium 是一款强大的 Web 自动化测试工具，包括 Selenium IDE、WebDriver 和 Grid 三大组件，支持多种编程语言和跨平台操作。它能有效提高测试效率，解决跨浏览器兼容性问题，进行性能测试和数据驱动测试，尽管存在学习曲线较陡、不稳定等缺点，但其优势明显，是自动化测试领域的首选工具。
恩爸编程
88 17
Selenium：强大的 Web 自动化测试工具
蚝油菜花
|
21天前
|
机器学习/深度学习 人工智能 算法
BALROG：基准测试工具，用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
BALROG 是一款用于评估大型语言模型（LLMs）和视觉语言模型（VLMs）在复杂动态环境中推理能力的基准测试工具。它通过一系列挑战性的游戏环境，如 NetHack，测试模型的规划、空间推理和探索能力。BALROG 提供了一个开放且细粒度的评估框架，推动了自主代理研究的进展。
蚝油菜花
31 3
BALROG：基准测试工具，用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
代码掌控者
|
14天前
|
算法 Java 测试技术
Benchmark.NET：让 C# 测试程序性能变得既酷又简单
Benchmark.NET是一款专为 .NET 平台设计的性能基准测试框架，它可以帮助你测量代码的执行时间、内存使用情况等性能指标。它就像是你代码的 "健身教练"，帮助你找到瓶颈，优化性能，让你的应用跑得更快、更稳！希望这个小教程能让你在追求高性能的路上越走越远，享受编程带来的无限乐趣！
代码掌控者
61 13
土木林森
|
20天前
|
并行计算 算法 测试技术
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略，涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略，涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面，旨在通过综合策略提升程序性能，满足实际需求。
土木林森
49 1
那年春天
|
26天前
|
监控 JavaScript 前端开发
如何在实际应用中测试和比较React和Vue的性能？
总之，通过多种方法的综合运用，可以相对客观地比较 React 和 Vue 在实际应用中的性能表现，为项目的选择和优化提供有力的依据。
那年春天
33 1
蓝易云
|
2天前
|
监控 JavaScript 测试技术
postman接口测试工具详解
Postman是一个功能强大且易于使用的API测试工具。通过详细的介绍和实际示例，本文展示了Postman在API测试中的各种应用。无论是简单的请求发送，还是复杂的自动化测试和持续集成，Postman都提供了丰富的功能来满足用户的需求。希望本文能帮助您更好地理解和使用Postman，提高API测试的效率和质量。
蓝易云
27 11
codetrend
|
1月前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库，使得更容易编写但愿测试代码。
codetrend
60 3
zzy的aly
|
2月前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算（目标检测）
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析（包括TP、FP、FN、TN、精准率和召回率），接口处理，数据集处理，以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例，用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
zzy的aly
74 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算（目标检测）

物联网

热门文章

最新文章

  • 1
    阿里云联合思普瑞上线平安社区服务平台 提供物联网一站式管理
  • 2
    uDevice Center - IoT在线开发板/设备平台
  • 3
    【云栖大会】AliOS Things宣布开源，支持物联网设备快速上云
  • 4
    在ESP32上使用umqtt接入阿里云物联网平台
  • 5
    【物联网】OpenWrt编译和修改基础--预科
  • 6
    物联网世界的普通话，编程语言一览
  • 7
    阿里云智能IoT事业部总裁库伟：解析阿里云物联网整体战略
  • 8
    阿里云物联网平台体验(树莓派+Python篇)
  • 9
    树莓派4&阿里云物联网平台上云开发实操
  • 10
    迎接“万物互联”时代：当5G遇上智能终端、物联网
  • 1
    「Mac畅玩鸿蒙与硬件46」UI互动应用篇23 - 自定义天气预报组件
    39
  • 2
    docker基础篇：安装tomcat
    87
  • 3
    「Mac畅玩鸿蒙与硬件45」UI互动应用篇22 - 评分统计工具
    101
  • 4
    「Mac畅玩鸿蒙与硬件44」UI互动应用篇21 - 随机励志语录生成器
    55
  • 5
    docker高级篇（大厂进阶）：安装mysql主从复制
    41
  • 6
    三分钟轻松搞定固定资产盘点--首码RFID资产盘点小助手
    22
  • 7
    docker高级篇（大厂进阶）：安装redis集群
    50
  • 8
    《docker高级篇（大厂进阶）：4.Docker网络》包括：是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
    89
  • 9
    本地部署MES生产管理系统，贝锐花生壳快速实现安全远程访问
    53
  • 10
    《docker高级篇（大厂进阶）：5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
    61

    • 相关课程

    更多
  • MSE微服务测试最佳实践 - 自动化回归

    • 相关电子书

    更多
  • 移动互联网测试到质量的转变
  • 给ITer的技术实战进阶课-阿里CIO学院独家教材（四）
  • F2etest — 多浏览器兼容性测试整体解决方案

    • 相关实验场景

    更多
  • 灵活弹性的PolarDB Serverless确保数据业务持续在线
  • 快速上手并跑通AnalyticDB PostgreSQL版TPC-H测试
    • 下一篇
    阿里云oss存储简介和如何使用