Performances des passerelles API open-source : APISIX 3.0 et Kong 3.0

Contexte

Apache APISIX est une passerelle API cloud-native, haute performance et évolutive. Elle est implémentée sur la base de NGINX et etcd. En plus des fonctionnalités des passerelles API traditionnelles, APISIX dispose de fonctionnalités de routage dynamique et de rechargement à chaud des plugins, ce qui la rend particulièrement puissante pour la gestion des API dans une architecture cloud-native.

À l'automne 2022, Apache APISIX et Kong ont publié leur version 3.0 presque simultanément. En particulier, les nouvelles fonctionnalités d'Apache APISIX 3.0 se concentrent sur l'écosystème, l'intelligence et les applications. Vous pouvez consulter Apache APISIX 3.0 : 11 points forts de la passerelle API open source pour en savoir plus.

Les deux sont d'excellentes passerelles API open source pour les microservices. Lorsque deux produits sont publiés simultanément, de nombreux utilisateurs s'intéressent à leurs différences de fonctionnalités et de performances. Dans cet article, nous présenterons les résultats de performance des tests sur quatre scénarios différents.

Méthode de test

Topologie des requêtes

Voici le diagramme de topologie des requêtes de test. L'outil de test de charge utilisé était wrk2, et le service en amont utilisé était OpenResty.

APISIX

Kong

Informations sur le serveur

Ce test a été effectué sur un serveur cloud de type Standard D8s v3 (8 vcpu, 32 GiB de mémoire). Tous les composants liés au test sont déployés sur ce serveur.

Environnement du serveur

Versions des logiciels

Voici les versions des logiciels utilisés dans ce test :

Configuration réseau

Lors du déploiement d'APISIX et de Kong dans Docker, nous avons utilisé le mode réseau hôte dans Docker pour éviter les implications réseau qui pourraient affecter les résultats des tests.

Déploiement

Nous avons choisi wrk2 comme outil de test de référence et OpenResty comme service en amont simulé. Nous avons déployé APISIX et Kong dans Docker avec une configuration déclarative activée pour les deux.

Nous voulions rendre les résultats des tests plus intuitifs, donc nous n'avons utilisé qu'un seul worker pour les tests. Généralement, la relation entre les capacités de charge et le nombre de workers est linéaire. Ainsi, un seul worker suffira pour les tests.

De plus, APISIX avait désactivé les plugins proxy-cache et proxy-mirror, qui sont mentionnés dans les documents liés aux benchmarks du projet APISIX (les plugins proxy-cache et proxy-mirror affectent les performances d'APISIX d'environ 4 %).

Consultez le script de déploiement et le script de test de référence ici.

Tests

Test #1 : 1 Route

Test du scénario de proxy pur. Nous utiliserons une seule route et aucun plugin pour tester les performances d'APISIX et Kong.

Configuration d'APISIX :

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

Configuration de Kong :

_format_version: "3.0"
_transform: true

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

Comparaison des performances

Nous avons utilisé la métrique QPS pour mesurer les performances. Un total de 10 tours de tests ont été effectués.

Comme nous pouvons le voir sur le graphique, dans le scénario de proxy pur, les performances d'APISIX 3.0 sont bien supérieures à celles de Kong 3.0. Le QPS moyen d'APISIX 3.0 sur 10 tours est de 14104, et le QPS moyen de Kong 3.0 sur 10 tours est de 9857. Les performances d'APISIX 3.0 sont 140% de celles de Kong 3.0.

Test #2 : 1 Route + 1 Plugin de limitation de débit

La limitation de débit est l'un des principaux scénarios d'utilisation des passerelles API. Donc, dans ce scénario, nous avons configuré les passerelles avec une route et un plugin de limitation de débit.

Configuration d'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

Configuration 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

Ce test mesure les performances des passerelles API dans le scénario de limitation de débit. Nous avons configuré le plugin de limitation de débit à une limite plus élevée pour éviter de déclencher une véritable action de limitation de débit.

Comparaison des performances

Encore une fois, nous avons effectué un total de 10 tours de tests. Nous pouvons voir sur le graphique qu'après l'activation du plugin de limitation de débit, le QPS d'APISIX 3.0 et de Kong 3.0 a tous deux considérablement baissé, mais le QPS de Kong 3.0 a baissé de manière plus notable. Le QPS moyen sur 10 tours d'APISIX 3.0 est de 9154, et le QPS moyen sur 10 tours de Kong 3.0 est de 4810. Dans ce scénario, les performances d'APISIX 3.0 sont 190% de celles de Kong 3.0.

Test #3 : 1 Route + 1 Plugin de limitation de débit + 1 Plugin d'authentification

L'authentification est un autre scénario d'utilisation courant des passerelles API.

Dans ce scénario, nous avons configuré les passerelles avec une route, un plugin de limitation de débit et un plugin d'authentification.

Configuration d'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

Configuration 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

Ce scénario couvre la limitation de débit et l'authentification, de sorte que plusieurs plugins fonctionnent ensemble dans le chemin de la requête. C'est un scénario typique d'utilisation de la passerelle API.

Comparaison des performances

Encore une fois, nous avons effectué dix tours de tests pour mesurer le QPS.

Nous pouvons voir sur le graphique qu'après l'activation des plugins limit-count et key-auth sur APISIX, le QPS moyen d'APISIX 3.0 est de 8933, ce qui est légèrement inférieur au QPS moyen de 9154 lorsque seul le plugin limit-count est activé.

Cependant, dans Kong 3.0, le QPS moyen est tombé à 3977, ce qui représente une baisse significative par rapport au QPS moyen de 4810 lorsque seul le plugin de limitation de débit est activé.

Dans ce scénario d'activation des plugins de limitation de débit et d'authentification, les performances d'APISIX 3.0 sont 220% de celles de Kong 3.0.

Test #4 : 5000 Routes

Ce test utilise des scripts pour générer 5000 routes uniques. Le test mesure les performances d'APISIX et de Kong pour la correspondance des routes : à quelle vitesse il trouve une correspondance.

Comparaison des performances

En 10 tours de tests, le QPS moyen d'APISIX 3.0 est de 13787, et celui de Kong 3.0 est de 9840. Les performances d'APISIX 3.0 sont 140% de celles de Kong 3.0.

Conclusion

D'après les résultats des tests sur plusieurs scénarios, il est évident que :

• les performances d'APISIX 3.0 sont environ 140% de celles de Kong 3.0 lorsque les plugins ne sont pas utilisés (Test #1 et Test #4).
• Les performances d'APISIX 3.0 sont environ 200% de celles de Kong 3.0 lorsque les plugins sont utilisés (Test #2 et Test #3).

Nous pouvons voir qu'APISIX maintient un avantage de performance considérable dans sa version 3.0.