Apache APISIX провел регрессионные тесты под платформой ARM64 и исправил некоторые проблемы совместимости скриптов сборки под платформой ARM64. С помощью краткого описания тестов развертывания в этой статье показано, что в среде AWS Graviton, как с точки зрения стабильности, так и с точки зрения обработки трафика, производительность APISIX весьма ослепительна.
Справочная информация
В конце мая 2022 года AWS выпустила новейший процессор семейства AWS Graviton на базе ARM – AWS Graviton3. Согласно официальным данным AWS, по сравнению с процессором Graviton2, основанным на передовой технологии памяти DDR5, процессор Graviton3 может обеспечить повышение производительности на 25%, в 2 раза увеличить производительность операций с плавающей запятой и на 50% увеличить скорость доступа к памяти; Graviton3 также потребляет на 60% меньше энергии на одном и том же экземпляре EC2 того же типа.
А что же с фактическими данными? Давайте на примере API-шлюза, требовательного к процессору, посмотрим, как работает AWS Graviton3. Здесь мы используем Apache APISIX для проведения сравнительных тестов производительности на серверных средах AWS Graviton2 (C6g) и AWS Graviton3 (C7g).
Apache APISIX – это облачно-нативный, высокопроизводительный, масштабируемый API-шлюз. Основанный на NGNIX+Lua JIT и etcd, по сравнению с традиционными API-шлюзами, APISIX обладает функциями динамической маршрутизации и горячей загрузки плагинов, что особенно подходит для управления API в облачной архитектуре.
Установка и развертывание
Подготовьте сервер с чипом ARM64, здесь мы выбираем Amazon EC2 C7g(Только эта модель теперь имеет AWS Graviton3), а операционной системой выбираем Ubuntu 20.04.
Не забудьте установить Docker:
sudo apt-get update && sudo apt-get install docker.io
Apache 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
2.Запустите APISIX
sudo docker run --net=host -d apache/apisix:2.14.1-alpine
3.Зарегистрировать маршрут
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 } }}'
4.Тест
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, а все следующие данные теста производительности выполняются на одноядерном процессоре.
Сценарий 1: Одиночный восходящий поток
Используйте один восходящий поток без каких-либо плагинов. Здесь в основном проверяется производительность APISIX в режиме чистого прокси-сервера от источника к источнику.
# apisix: 1 worker + 1 upstream + no plugin
# register route
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
}
}
}'
Сценарий 2: Один восходящий поток + два плагина
Использование одного восходящего потока и двух плагинов. В основном тестируется производительность APISIX при включении двух основных плагинов, потребляющих производительность – limit-count и prometheus.
# apisix: 1 worker + 1 upstream + 2 plugins (limit-count + prometheus)
# register route
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
- Сравнение задержек
Одиночный восходящий поток | Одиночный поток + два плагина | |||
AWS Гравитон2 | AWS Гравитон3 | AWS Гравитон2 | AWS Гравитон3 | |
QPS (запрос/с) | 13000 | 23000 (Увеличение на 76%) | 11000 | 18000 (Увеличение на 63%) |
Латентность (мс) | 1.11 | 0,68 (Уменьшение на 38%) | 1.39 | 0,88 (Уменьшение на 37%) |
Из приведенных выше данных также видно, что в сценарии вычислений с интенсивным использованием процессора, таких как API Gateway, AWS Graviton3 повышает производительность на 76% по сравнению с AWS Graviton2, при этом снижая задержку на 38%. Эти данные даже лучше, чем официальные данные AWS, упомянутые в начале (повышение производительности на 25%).
Подведем итоги
В этой статье для сравнения производительности AWS Graviton3 и AWS Graviton2 в основном использовался Apache APISIX. Видно, что в сценарии API-шлюза с интенсивными вычислениями на CPU, AWS Graviton3, можно сказать, демонстрирует свойства монстра производительности. Конечно, рекомендуется много практиковаться и в будущем ожидать больше тестовых данных для проектов с интенсивными вычислениями.