Rendimiento de las pasarelas API de código abierto: APISIX 3.0 y Kong 3.0

Antecedentes

Apache APISIX es una puerta de enlace API nativa de la nube, de alto rendimiento y escalable. Está implementado basándose en NGINX y etcd. Además de las características de las puertas de enlace API tradicionales, APISIX tiene características de enrutamiento dinámico y recarga en caliente de plugins, lo que lo hace especialmente potente para la gestión de API en arquitecturas nativas de la nube.

En el otoño de 2022, Apache APISIX y Kong lanzaron su versión 3.0 casi al mismo tiempo. En particular, las nuevas características de Apache APISIX 3.0 se centran en el ecosistema, la inteligencia y las aplicaciones. Puedes consultar Apache APISIX 3.0: 11 aspectos destacados de la puerta de enlace API de código abierto para obtener más información.

Ambos son excelentes puertas de enlace API de código abierto para microservicios. Cuando dos productos se lanzan simultáneamente, muchos usuarios están interesados en las diferencias de características y rendimiento. En este artículo, proporcionaremos los resultados de rendimiento de las pruebas en cuatro escenarios diferentes.

Método de Prueba

Topología de Solicitudes

A continuación se muestra el diagrama de topología de las solicitudes de prueba. La herramienta de prueba de estrés utilizada fue wrk2, y el servicio ascendente utilizado fue OpenResty.

APISIX

Kong

Información del Servidor

Esta prueba se realizó en un servidor en la nube con Standard D8s v3 (8 vcpu, 32 GiB de memoria). Todos los componentes relacionados con la prueba se implementaron en este servidor.

Entorno del Servidor

Versiones de Software

Las siguientes son las versiones de software utilizadas en esta prueba:

Configuración de Red

Al implementar APISIX y Kong en docker, utilizamos el modo de red host en docker para evitar implicaciones de red que puedan afectar los resultados de la prueba.

Implementación

Elegimos wrk2 como la herramienta de prueba de referencia y OpenResty como el servicio ascendente simulado. Implementamos APISIX y Kong en docker con configuración declarativa habilitada para ambos.

Queríamos que los resultados de la prueba fueran más intuitivos, por lo que solo utilizamos un trabajador para las pruebas. Normalmente, la relación entre las capacidades de carga y el número de trabajadores es lineal. Por lo tanto, solo un trabajador será suficiente para las pruebas.

Además, APISIX había desactivado los plugins proxy-cache y proxy-mirror, que se mencionan en los documentos relacionados con pruebas de referencia en el proyecto APISIX (los plugins proxy-cache y proxy-mirror afectan el rendimiento de APISIX en aproximadamente un 4%).

Consulta aquí la referencia del script de implementación y prueba.

Pruebas

Prueba #1: 1 Ruta

Prueba del escenario de proxy puro. Solo usaremos una ruta y ningún plugin para probar el rendimiento de APISIX y Kong.

Configuración de APISIX:

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

Configuración de Kong:

_format_version: "3.0"
_transform: true

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

Comparación de Rendimiento

Utilizamos la métrica QPS para medir el rendimiento. Se realizaron un total de 10 rondas de pruebas.

Como podemos ver en el gráfico, en el escenario de proxy puro, el rendimiento de APISIX 3.0 es mucho mayor que el de Kong 3.0. El QPS promedio de APISIX 3.0 en 10 rondas es 14104, y el QPS promedio de Kong 3.0 en 10 rondas es 9857. El rendimiento de APISIX 3.0 es 140% del de Kong 3.0.

Prueba #2: 1 Ruta + 1 Plugin de Limitación de Tasa

La limitación de tasa es uno de los escenarios principales de los usuarios de puertas de enlace API. Por lo tanto, en este escenario, configuramos las puertas de enlace con una ruta y un plugin de limitación de tasa.

Configuración de 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

Configuración de 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

Esta prueba mide el rendimiento de las puertas de enlace API en el escenario de limitación de tasa. Configuramos el plugin de limitación de tasa con un límite más alto para evitar desencadenar una acción real de limitación de tasa.

Comparación de Rendimiento

Nuevamente, realizamos un total de 10 rondas de pruebas. Podemos ver en el gráfico que después de habilitar el plugin de limitación de tasa, el QPS de APISIX 3.0 y Kong 3.0 disminuyó significativamente, pero el QPS de Kong 3.0 disminuyó notablemente más. El QPS promedio de 10 rondas de APISIX 3.0 es 9154, y el QPS promedio de 10 rondas de Kong 3.0 es 4810. En este escenario, el rendimiento de APISIX 3.0 es 190% del de Kong 3.0.

Prueba #3: 1 Ruta + 1 Plugin de Limitación de Tasa + 1 Plugin de Autenticación

La autenticación es otro escenario común de los usuarios de la puerta de enlace API.

En este escenario, configuramos las puertas de enlace con una ruta, un plugin de limitación de tasa y un plugin de autenticación.

Configuración de 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

Configuración de 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

Este escenario cubre la limitación de tasa y la autenticación, de modo que múltiples plugins trabajen juntos en la ruta de solicitud. Es un escenario típico que utiliza la puerta de enlace API.

Comparación de Rendimiento

Nuevamente, realizamos diez rondas de pruebas para medir el QPS.

Podemos ver en el gráfico que después de habilitar los plugins limit-count y key-auth en APISIX, el QPS promedio de APISIX 3.0 es 8933, que es solo ligeramente inferior al QPS promedio de 9154 cuando solo se habilita el plugin limit-count.

En Kong 3.0, sin embargo, el QPS promedio disminuyó a 3977, lo que es una disminución significativa en comparación con el QPS promedio de 4810 cuando solo se habilita el plugin de limitación de tasa.

En este escenario de habilitar plugins de limitación de tasa y autenticación, el rendimiento de APISIX 3.0 es 220% del de Kong 3.0.

Prueba #4: 5000 Rutas

Esta prueba utiliza scripts para generar 5000 rutas únicas. La prueba mide el rendimiento de APISIX y Kong para la coincidencia de rutas: qué tan rápido encuentra una coincidencia.

Comparación de Rendimiento

En 10 rondas de pruebas, el QPS promedio de APISIX 3.0 es 13787, y el promedio de Kong 3.0 es 9840. El rendimiento de APISIX 3.0 es 140% del de Kong 3.0.

Conclusión

De los resultados de las pruebas en múltiples escenarios, es evidente que:

• El rendimiento de APISIX 3.0 es aproximadamente 140% del de Kong 3.0 cuando no se utilizan plugins (Prueba #1 y Prueba #4).
• El rendimiento de APISIX 3.0 es aproximadamente 200% del de Kong 3.0 cuando se utilizan plugins (Prueba #2 y Prueba #3).

Podemos ver que APISIX mantiene una ventaja considerable en rendimiento en su versión 3.0.