当前位置:网站首页>ARM64 上的性能怪兽:API 网关 Apache APISIX 在 AWS Graviton3 上的安装和性能测试
ARM64 上的性能怪兽:API 网关 Apache APISIX 在 AWS Graviton3 上的安装和性能测试
2022-06-13 11:00:00 【ApacheAPISIX】
背景
AWS 在 2022 年 5 月底发布了最新的基于 ARM 架构的 AWS Graviton 系列处理器——AWS Graviton3。据 AWS 官方数据显示,与 Graviton2 处理器相比,基于领先的 DDR5 内存技术,Graviton3 处理器可提供高达 25% 的性能提升、高达 2 倍的浮点性能以及 50% 的内存访问速度;在性能与同类 EC2 实例相同的情况下,Graviton3 还可减少 60% 的能源。
那么实际数据会怎样呢?让我们以 CPU 密集型的 API 网关为例,来看看 AWS Graviton3 的表现如何。在这里我们使用 Apache APISIX 在 AWS Graviton2(C6g)和 AWS Graviton3(C7g) 两种服务器环境下进行性能对比测试。
Apache APISIX 是一个云原生、高性能、可扩展的 API 网关。基于 NGNIX+LuaJIT 和 etcd 来实现,和传统 API 网关相比,APISIX 具备动态路由和插件热加载的特点,特别适合云原生架构下的 API 管理。
准备:安装部署
在进行测试前,需要准备一台搭载 ARM64 芯片的服务器,这里我们选用了 Amazon EC2 C7g(现在只有这个型号才搭载 AWS Graviton3),操作系统选择了 Ubuntu 20.04。
同时安装 Docker。
sudo apt-get update && sudo apt-get install docker.io
目前,APISIX 已经发布了最新版本的 ARM64 镜像,可以使用 Docker 方式进行一键部署。具体过程可参考下方:
- 启动 etcd
sudo docker run -d \
--name etcd -p 2379:2379 -e ETCD_UNSUPPORTED_ARCH=arm64 \
-e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
-e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
rancher/coreos-etcd:v3.4.16-arm64
- 启动 APISIX
sudo docker run --net=host -d apache/apisix:2.14.1-alpine
- 注册路由
curl "http://127.0.0.1:9080/apisix/admin/routes/1" \
-H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
"uri": "/anything/*",
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
}
}'
- 访问测试
curl -i http://127.0.0.1:9080/anything/das
HTTP/1.1 200 OK
.....
AWS Graviton2 和 AWS Graviton3 的性能对比
根据前文的操作,基于官方脚本成功完成了 APISIX 在 AWS Graviton3 处理器上安装和兼容性测试。下面让我们来看看 Apache APISIX 在 AWS Graviton2(C6g)和 AWS Graviton3(C7g)上的性能表现。
为了方便测试,本示例中 APISIX 只开启了一个 Worker,下面的性能测试数据都是在单核 CPU 上运行的。
场景一:单个上游
该场景下使用单个上游(不包含任何插件),主要测试 APISIX 在纯代理回源模式下的性能表现。在本地环境中进行测试:
# apisix: 1 worker + 1 upstream + no plugin
# 注册路由
curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "plugins": { }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980":1 } } }'
场景二:单上游+多插件
另一场景则使用单上游与多插件配合,在这里使用了两个插件。主要测试 APISIX 在开启 limit-count
和 prometheus
两个核心消耗性能插件时的性能表现。
# apisix: 1 worker + 1 upstream + 2 plugins (limit-count + prometheus)
# 注册路由
curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "plugins": { "limit-count": { "count": 2000000000000, "time_window": 60, "rejected_code": 503, "key": "remote_addr" }, "prometheus": {} }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980":1 } } }'
数据对比
在上述两种场景下,分别从请求处理和延迟时间两个层面进行了相关测试与对比。结果如下:
- QPS 对比
- Latency 对比
单个上游 | 单个上游+两个插件 | |||
AWS Graviton2 | AWS Graviton3 | AWS Graviton2 | AWS Graviton3 | |
QPS(request/s) | 13000 | 23000(提升76%) | 11000 | 18000(提升63%) |
Latency(ms) | 1.11 | 0.68(降低38%) | 1.39 | 0.88(降低37%) |
从上方数据可以看到,在 API 网关这样 CPU 密集型的计算场景下,AWS Graviton3 比 AWS Graviton2 的性能提升了 76%,同时延迟还降低了 38%。这个数据比开头提到的 AWS 官方给出的数据(25%性能提升)还要优异。
总结
本文主要通过使用 Apache APISIX 进行了 AWS Graviton3 与 AWS Graviton2 的性能对比,可以看到在 API 网关 CPU 密集型的计算场景下,AWS Graviton3 可谓展示了性能怪兽的属性。当然,也推荐大家多多进行实践,期待后续更多计算密集型项目的测试数据。
边栏推荐
- 日志1111
- pyepics下载和安装
- As a tester, these basic knowledge are essential
- 数据库学习笔记(第十六章)
- [elm classification] data classification based on particle swarm optimization convolution neural network CNN combined with limit learning machine elm with matlab code
- winform 解决黑屏 频繁刷新
- Gauss elimination for solving N-element equations
- 求组合数四种方法
- 关于 SAP Spartacus CmsService.getComponentData 可能的优化思路
- C file package and download
猜你喜欢
基于Vue+Nest.js+MySQL的跨平台开源社区运营管理系统
Flutter simple and excellent open source dialog uses free_ dialog
Anonymity in Web3 and NFT
宝塔访问从IP改为域名
区间修改乘和加(理解懒标记的好例题)
【TcaplusDB知识库】TcaplusDB常规单据介绍
flutter简单优秀的开源dialog使用free_dialog
【TcaplusDB知识库】TcaplusDB运维单据介绍
ue5 小知识点 geometry script modeling
C#/VB.NET 在Word转PDF时生成目录书签
随机推荐
[elm classification] data classification based on particle swarm optimization convolution neural network CNN combined with limit learning machine elm with matlab code
容斥原理(能被整除的数)
【TcaplusDB知识库】TcaplusDB单据受理-创建业务介绍
Redis相关
终于,月入 20000 !!
Ipdu handling caused by mode change of COM
F2. nearest beautiful number (hard version)
[tool chain series] Notepad++
宝塔访问从IP改为域名
数据库学习笔记(第十六章)
Codeforces Round #798 (Div. 2)ABCD
View the default MySQL password in the pagoda
Codeforces Round #798 (Div. 2)ABCD
Acwing game 55
What is 400g Ethernet?
Similarities and differences between decoration mode and agency mode
SSM integration preliminary details
服务器的使用
MFC custom button to realize color control
There is no suspense about the first one in the overtime table of the Internet company!