Производительность Open-Source API Gateway: APISIX 3.0 и Kong 3.0

Zhengsong Tu

November 3, 2022

Products

Предыстория

Apache APISIX — это облачный, высокопроизводительный, масштабируемый API-шлюз. Он реализован на основе NGINX и etcd. Помимо функций традиционных API-шлюзов, APISIX обладает возможностями динамической маршрутизации и горячей перезагрузки плагинов, что делает его особенно мощным инструментом для управления API в облачной архитектуре.

Архитектура Apache APISIX

Осенью 2022 года Apache APISIX и Kong почти одновременно выпустили свои версии 3.0. В частности, новые функции Apache APISIX 3.0 сосредоточены на экосистеме, интеллектуальных возможностях и приложениях. Подробнее можно узнать в статье Apache APISIX 3.0: 11 основных моментов открытого API-шлюза.

Оба продукта являются отличными открытыми API-шлюзами для микросервисов. Когда два продукта выпускаются одновременно, многие пользователи интересуются их функциональными и производительностными различиями. В этой статье мы представим результаты тестирования производительности в четырех различных сценариях.

Методология тестирования

Топология запросов

Ниже приведена топологическая диаграмма тестовых запросов. В качестве инструмента для нагрузочного тестирования использовался wrk2, а в качестве вышестоящего сервиса — OpenResty.

APISIX

Топология запросов APISIX

Kong

Топология запросов Kong

Информация о сервере

Тестирование проводилось на облачном сервере Standard D8s v3 (8 vcpu, 32 GiB памяти). Все компоненты, связанные с тестированием, были развернуты на этом сервере.

Окружение сервера

НазваниеЗначение
ОСDebian 10 "buster"
ulimit -n65535

Версии программного обеспечения

Ниже приведены версии программного обеспечения, использованного в этом тесте:

НазваниеВерсия
Docker20.10.18, сборка b40c2f6
APISIX3.0.0
Kong3.0.0
Вышестоящий сервисOpenResty 1.21.4.1
Инструмент тестированияwrk2

Настройка сети

При развертывании APISIX и Kong в docker мы использовали режим host network в docker, чтобы избежать влияния сети на результаты тестирования.

Развертывание

Мы выбрали wrk2 в качестве инструмента для тестирования производительности и OpenResty в качестве симулятора вышестоящего сервиса. Мы развернули APISIX и Kong в docker с включенной декларативной конфигурацией для обоих.

Мы хотели сделать результаты тестирования более наглядными, поэтому использовали только один рабочий процесс для тестирования. Обычно зависимость между нагрузочной способностью и количеством рабочих процессов является линейной. Поэтому одного рабочего процесса будет достаточно для тестирования.

Кроме того, в APISIX были отключены плагины proxy-cache и proxy-mirror, которые упоминаются в документах, связанных с тестированием производительности в проекте APISIX (плагины proxy-cache и proxy-mirror влияют на производительность APISIX примерно на 4%).

Ссылка на скрипт развертывания и тестовый скрипт.

Тесты

Тест №1: 1 маршрут

Тестирование сценария чистого прокси. Мы будем использовать только один маршрут и никаких плагинов для тестирования производительности APISIX и Kong.

Конфигурация APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
#END

Конфигурация Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello

Сравнение производительности

performance(1).png

Мы использовали метрику QPS для измерения производительности. Всего было проведено 10 раундов тестирования.

Как видно из графика, в сценарии чистого прокси производительность APISIX 3.0 значительно выше, чем у Kong 3.0. Средний QPS APISIX 3.0 за 10 раундов составляет 14104, а средний QPS Kong 3.0 за 10 раундов — 9857. Производительность APISIX 3.0 составляет 140% от Kong 3.0.

Тест №2: 1 маршрут + 1 плагин ограничения скорости

Ограничение скорости — один из основных сценариев использования API-шлюзов. Поэтому в этом сценарии мы настроили шлюзы с одним маршрутом и одним плагином ограничения скорости.

Конфигурация APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
#END

Конфигурация Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local

Этот тест измеряет производительность API-шлюзов в сценарии ограничения скорости. Мы настроили плагин ограничения скорости на высокий лимит, чтобы избежать срабатывания реального ограничения скорости.

Сравнение производительности

performance(2).png

Снова мы провели 10 раундов тестирования. Как видно из графика, после включения плагина ограничения скорости QPS APISIX 3.0 и Kong 3.0 значительно снизились, но QPS Kong 3.0 снизился заметно больше. Средний QPS APISIX 3.0 за 10 раундов составляет 9154, а средний QPS Kong 3.0 за 10 раундов — 4810. В этом сценарии производительность APISIX 3.0 составляет 190% от Kong 3.0.

Тест №3: 1 маршрут + 1 плагин ограничения скорости + 1 плагин аутентификации

Аутентификация — еще один распространенный сценарий использования API-шлюза.

В этом сценарии мы настроили шлюзы с одним маршрутом, одним плагином ограничения скорости и одним плагином аутентификации.

Конфигурация APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      key-auth:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
consumers:
  - username: jack
    plugins:
        key-auth:
            key: user-key
#END

Конфигурация Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local
    - name: key-auth
      config:
        key_names:
          - apikey
consumers:
- username: my-user
  keyauth_credentials:
  - key: my-key

Этот сценарий охватывает ограничение скорости и аутентификацию, чтобы несколько плагинов работали вместе в пути запроса. Это типичный сценарий использования API-шлюза.

Сравнение производительности

performance(3).png

Снова мы провели 10 раундов тестирования для измерения QPS.

Как видно из графика, после включения плагинов limit-count и key-auth в APISIX средний QPS APISIX 3.0 составляет 8933, что лишь немного ниже среднего QPS 9154, когда включен только плагин limit-count.

В Kong 3.0, однако, средний QPS упал до 3977, что является значительным снижением по сравнению со средним QPS 4810, когда включен только плагин ограничения скорости.

В этом сценарии включения плагинов ограничения скорости и аутентификации производительность APISIX 3.0 составляет 220% от Kong 3.0.

Тест №4: 5000 маршрутов

Этот тест использует скрипты для генерации 5000 уникальных маршрутов. Тест измеряет производительность APISIX и Kong для сопоставления маршрутов: насколько быстро происходит совпадение.

Сравнение производительности

performance(4).png

В 10 раундах тестирования средний QPS APISIX 3.0 составляет 13787, а средний QPS Kong 3.0 — 9840. Производительность APISIX 3.0 составляет 140% от Kong 3.0.

Заключение

Из результатов тестирования в нескольких сценариях очевидно, что:

  • производительность APISIX 3.0 составляет около 140% от Kong 3.0, когда плагины не используются (Тест №1 и Тест №4).
  • Производительность APISIX 3.0 составляет около 200% от Kong 3.0, когда плагины используются (Тест №2 и Тест №3).

Мы видим, что APISIX сохраняет значительное преимущество в производительности в своей версии 3.0.

Tags:
APISIX Basics
Alternatives to Kong
Comparison to Competitors