关于amazon-web-services:ARM64-上的性能怪兽API-网关-Apache-APISIX-在-AWS-Graviton3-上的安装和性能测试

53次阅读

共计 2553 个字符,预计需要花费 7 分钟才能阅读完成。

背景

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 形式进行一键部署。具体过程可参考下方:

  1. 启动 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
  1. 启动 APISIX
sudo docker run --net=host -d apache/apisix:2.14.1-alpine
  1. 注册路由
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}
  }
}'
  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-countprometheus 两个外围耗费性能插件时的性能体现。

# 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}
    }
}'

数据比照

在上述两种场景下,别离从申请解决和延迟时间两个层面进行了相干测试与比照。后果如下:

  1. QPS 比照

  1. 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 堪称展现了性能怪兽的属性。当然,也举荐大家多多进行实际,期待后续更多计算密集型我的项目的测试数据。

正文完
 0