ARM64 上的效能怪獸：API 閘道器 Apache APISIX 在 AWS Graviton3 上的安裝和效能測試

Apache_APISIX發表於2022-06-09
APIApache

背景

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 管理。

Apache APISIX

準備：安裝部署

在進行測試前，需要準備一臺搭載 ARM64 晶片的伺服器，這裡我們選用了 Amazon EC2 C7g（現在只有這個型號才搭載 AWS Graviton3），作業系統選擇了 Ubuntu 20.04。

Amazon EC2

同時安裝 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-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
        }
    }
}'

資料對比

在上述兩種場景下，分別從請求處理和延遲時間兩個層面進行了相關測試與對比。結果如下：

  1. QPS 對比

QPS

  1. Latency 對比

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 可謂展示了效能怪獸的屬性。當然，也推薦大家多多進行實踐，期待後續更多計算密集型專案的測試資料。

相關文章