Leistungen des Open-Source API-Gateways: APISIX 3.0 und Kong 3.0

Hintergrund

Apache APISIX ist ein Cloud-nativer, hochleistungsfähiger und skalierbarer API-Gateway. Es basiert auf NGINX und etcd implementiert. Neben den Funktionen traditioneller API-Gateways verfügt APISIX über Funktionen wie dynamisches Routing und Plugin-Hot-Reloading, was es besonders leistungsstark für das API-Management in Cloud-nativen Architekturen macht.

Im Herbst 2022 veröffentlichten Apache APISIX und Kong fast gleichzeitig ihre Version 3.0. Insbesondere konzentrieren sich die neuen Funktionen von Apache APISIX 3.0 auf Ökosystem, Intelligenz und Anwendungen. Weitere Informationen finden Sie unter Apache APISIX 3.0: 11 Highlights des Open-Source-API-Gateways.

Beide sind hervorragende Open-Source-API-Gateways für Microservices. Wenn zwei Produkte gleichzeitig veröffentlicht werden, sind viele Benutzer an den Unterschieden in ihren Funktionen und ihrer Leistung interessiert. In diesem Artikel werden wir die Leistungsergebnisse der Tests in vier verschiedenen Szenarien vorstellen.

Testmethode

Anforderungstopologie

Das folgende Diagramm zeigt die Topologie der Testanforderungen. Das verwendete Lasttest-Tool war wrk2, und der verwendete Upstream-Dienst war OpenResty.

APISIX

Kong

Serverinformationen

Dieser Test wurde auf einem Cloud-Server mit Standard D8s v3 (8 vCPU, 32 GiB RAM) durchgeführt. Alle testrelevanten Komponenten sind auf diesem Server bereitgestellt.

Serverumgebung

Softwareversionen

Die folgenden Softwareversionen wurden in diesem Test verwendet:

Netzwerkeinstellung

Bei der Bereitstellung von APISIX und Kong in Docker verwendeten wir den Host-Netzwerkmodus in Docker, um Netzwerkeffekte zu vermeiden, die die Testergebnisse beeinflussen könnten.

Bereitstellung

Wir wählten wrk2 als Benchmark-Testtool und OpenResty als simulierten Upstream. Wir haben APISIX und Kong in Docker mit deklarativer Konfiguration bereitgestellt.

Um die Testergebnisse intuitiver zu gestalten, verwendeten wir nur einen Worker für die Tests. In der Regel ist die Beziehung zwischen der Lastkapazität und der Anzahl der Worker linear. Daher reicht ein Worker für die Tests aus.

Außerdem wurden bei APISIX die Plugins proxy-cache und proxy-mirror deaktiviert, die in den Benchmark-bezogenen Dokumenten des APISIX-Projekts erwähnt werden (die Plugins proxy-cache und proxy-mirror beeinflussen die Leistung von APISIX um etwa 4%).

Hier finden Sie die Bereitstellungsskripte und Testskriptreferenzen.

Tests

Test #1: 1 Route

Testen Sie das reine Proxy-Szenario. Wir verwenden nur eine Route und keine Plugins, um die Leistung von APISIX und Kong zu testen.

APISIX-Konfiguration:

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

Kong-Konfiguration:

_format_version: "3.0"
_transform: true

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

Leistungsvergleich

Wir verwendeten das QPS-Metrik, um die Leistung zu messen. Insgesamt wurden 10 Testrunden durchgeführt.

Wie aus der Grafik ersichtlich ist, ist die Leistung von APISIX 3.0 im reinen Proxy-Szenario deutlich höher als die von Kong 3.0. Der durchschnittliche QPS von APISIX 3.0 in 10 Runden beträgt 14104, und der durchschnittliche QPS von Kong 3.0 in 10 Runden beträgt 9857. Die Leistung von APISIX 3.0 beträgt 140% von Kong 3.0.

Test #2: 1 Route + 1 Rate-limiting Plugin

Rate Limiting ist eines der primären Anwendungsszenarien von API-Gateways. Daher haben wir in diesem Szenario die Gateways mit einer Route und einem Rate-Limiting-Plugin konfiguriert.

APISIX-Konfiguration:

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-Konfiguration:

_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

Dieser Test misst die Leistung der API-Gateways im Rate-Limiting-Szenario. Wir haben das Rate-Limiting-Plugin auf einen höheren Grenzwert konfiguriert, um eine echte Rate-Limiting-Aktion zu vermeiden.

Leistungsvergleich

Wieder führten wir insgesamt 10 Testrunden durch. Wie aus der Grafik ersichtlich ist, sank der QPS von APISIX 3.0 und Kong 3.0 nach der Aktivierung des Rate-Limiting-Plugins deutlich, aber der QPS von Kong 3.0 sank deutlich stärker. Der durchschnittliche 10-Runden-QPS von APISIX 3.0 beträgt 9154, und der durchschnittliche 10-Runden-QPS von Kong 3.0 beträgt 4810. In diesem Szenario beträgt die Leistung von APISIX 3.0 190% von Kong 3.0.

Test #3: 1 Route + 1 Rate-limiting Plugin + 1 Authentifizierungs-Plugin

Authentifizierung ist ein weiteres häufiges Anwendungsszenario von API-Gateways.

In diesem Szenario haben wir die Gateways mit einer Route, einem Rate-Limiting-Plugin und einem Authentifizierungs-Plugin konfiguriert.

APISIX-Konfiguration:

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-Konfiguration:

_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

Dieses Szenario deckt Rate Limiting und Authentifizierung ab, sodass mehrere Plugins im Anforderungspfad zusammenarbeiten. Es ist ein typisches Szenario, das das API-Gateway verwendet.

Leistungsvergleich

Wieder führten wir zehn Testrunden durch, um den QPS zu messen.

Wie aus der Grafik ersichtlich ist, beträgt der durchschnittliche QPS von APISIX 3.0 nach der Aktivierung der Plugins limit-count und key-auth 8933, was nur geringfügig niedriger ist als der durchschnittliche QPS von 9154, wenn nur das limit-count-Plugin aktiviert ist.

Bei Kong 3.0 sank der durchschnittliche QPS jedoch auf 3977, was einen deutlichen Rückgang im Vergleich zum durchschnittlichen QPS von 4810 darstellt, wenn nur das Rate-Limiting-Plugin aktiviert ist.

In diesem Szenario der Aktivierung von Rate-Limiting- und Authentifizierungs-Plugins beträgt die Leistung von APISIX 3.0 220% von Kong 3.0.

Test #4: 5000 Routen

Dieser Test verwendet Skripte, um 5000 eindeutige Routen zu generieren. Der Test misst die Leistung von APISIX und Kong für das Routen-Matching: wie schnell es einen Treffer erzielt.

Leistungsvergleich

In 10 Testrunden beträgt der durchschnittliche QPS von APISIX 3.0 13787, und der Durchschnitt von Kong 3.0 beträgt 9840. Die Leistung von APISIX 3.0 beträgt 140% von Kong 3.0.

Fazit

Aus den Ergebnissen der Tests in mehreren Szenarien geht deutlich hervor:

• Die Leistung von APISIX 3.0 beträgt etwa 140% von Kong 3.0, wenn keine Plugins verwendet werden (Test #1 und Test #4).
• Die Leistung von APISIX 3.0 beträgt etwa 200% von Kong 3.0, wenn Plugins verwendet werden (Test #2 und Test #3).

Wir können sehen, dass APISIX in seiner Version 3.0 einen erheblichen Leistungsvorteil beibehält.