Ist Ihre API echtzeitfähig? Testen Sie ihre Latenz mit dem rtapi-Tool von NGINX

NGINX | 11. März 2020

[Redaktion – Dieser Beitrag wurde um Informationen zu den überarbeiteten Berichten ergänzt, die mit rtapi Version 0.2.0 eingeführt wurden.]

APIs bilden das Herzstück moderner Anwendungen und sich weiterentwickelnder digitaler Architekturen. Laut dem Akamai State of the Internet Security Report entfallen 83 % des gesamten Web-Traffics auf API-Aufrufe. In der heutigen digitalen Welt, in der Verbraucher so einfach zu einem Mitbewerber wechseln können, ist eine positive Erfahrung mit Ihrer Website oder App von größter Bedeutung. Geschwindigkeit wird besonders geschätzt und hängt letztlich von reaktionsschnellen, zuverlässigen und anpassungsfähigen APIs ab. Wenn Sie hier alles richtig machen – Ihre API also schneller ist als die Ihres Mitbewerbers –, werden sich Entwickler für Sie entscheiden.

Laut dem IDC-Bericht APIs – die entscheidenden Faktoren für Erfolg oder Misserfolg digitaler Unternehmen erwarten über 90 % der Unternehmen eine Latenz von weniger als 50 Millisekunden (ms), während fast 60 % eine Latenz von 20 ms oder weniger erwarten. (Die Latenz ist definiert als die Zeit, die Ihre API-Infrastruktur benötigt, um auf einen API-Aufruf zu reagieren – vom Eingang einer Anfrage am API-Gateway bis zur Rückgabe des ersten Bytes einer Antwort an den Client.)

Auf Grundlage dieser Daten und einiger End-to-End-Analysen des API-Lebenszyklus definieren wir eine Echtzeit-API als eine API mit einer Latenz von höchstens 30 ms. Darüber hinaus muss der Latenzgrenzwert von 30 ms bis einschließlich zum 99. Perzentil der verarbeiteten Anfragen eingehalten werden (das bedeutet, dass im Durchschnitt nur eine von 100 Anfragen länger als 30 ms dauert). Weitere Informationen finden Sie in unserem Blogbeitrag zum Performance-Benchmarking von API-Management-Lösungen.

Für die meisten Unternehmen ist es eine große Herausforderung, API-Aufrufe möglichst in Echtzeit zu verarbeiten – insbesondere, wenn architektonisch komplexe API-Gateways als Zugangspunkte zu ihren API-Endpunkten dienen. Wie schneiden Ihre APIs also ab? Sind sie bereits schnell genug, um als echtzeitfähig zu gelten, oder müssen sie optimiert werden? Fühlt sich Ihr Produkt etwas träge an, ohne dass Sie genau sagen können, woran es liegt? Vielleicht wissen Sie auch nicht genau, wie hoch die Latenz Ihrer APIs ist?

Hier kommt rtapi ins Spiel – ein von NGINX entwickeltes Benchmarking-Tool für API-Latenzen in Echtzeit, das die Reaktionsfähigkeit Ihrer API-Gateways und Endpunkte testet und Berichte erstellt, die Sie ganz einfach an Ihre Kollegen weitergeben und mit ihnen besprechen können. Es stehen zwei Berichtsformate zur Verfügung: eine PDF-Datei mit einer zusammenfassenden Grafik und eine ASCII-formatierte Tabelle mit detaillierten Messwerten.

Ausführen von rtapi

  1. Laden Sie die rtapi-Binärdatei mit einer der beiden folgenden Methoden von GitHub herunter:
    • Wenn Sie Golang installiert haben, führen Sie diesen Befehl aus:
$ go get github.com/nginxinc/rtapi
  • Wenn Sie Golang nicht installiert haben, rufen Sie github.com/nginxinc/rtapi/releases auf, laden Sie die Binärdatei für Ihre Plattform herunter und machen Sie sie ausführbar.
  1. Geben Sie einen oder mehrere API-Endpunkte (Ziele) an, die Sie abfragen möchten, und verwenden Sie dabei das JSON- oder YAML-Format wie in den folgenden Beispielen. Wir empfehlen, die JSON- oder YAML-Daten in einer Datei namens endpoints.json bzw. endpoints.yml zu speichern. (Bei JSON können Sie die Daten im nächsten Schritt auch direkt in der rtapi-Befehlszeile als Parameter für die Option --data angeben.) Die einzigen erforderlichen Parameter für jeden Endpunkt sind target.url und target.method. Wenn Sie target.body und target.header nicht angeben, bleiben sie leer. Wenn Sie einen Parameter im Objekt query_parameters nicht angeben, verwendet rtapi dafür den in den folgenden Beispielen gezeigten (Standard-)Wert. Beispiel für eine JSON-Eingabe
[
  {
    "target": {
      "url": "https://www.example.com",
      "method": "POST",
      "body": "{\"id\":\"0\"}",
      "header": {
        "Content-Type": [
          "application/json"
        ]
      }
    },
    "query_parameters": {
      "threads": 2,
      "max_threads": 2,
      "connections": 10,
      "duration": "10s",
      "request_rate": 500
    }
  }
]
  1. Beispiel für eine YAML-Eingabe
- target:    url: https://example.com/api/id
    method: POST
    body: '{"id":"0"}'
    header:
      Content-Type:
        - application/json
  query_parameters:
    threads: 2
    max_threads: 2
    connections: 12
    duration: 10s
    request_rate: 500
  1. Führen Sie den folgenden Befehl aus, wobei --file die Datei mit der im JSON-/YAML-Format vorliegenden Liste der API-Endpunkte angibt und --output den PDF-Bericht angibt, der von rtapi erstellt werden soll. (Wie in Schritt 2 erwähnt, können Sie die JSON-Eingabe über die Befehlszeile bereitstellen: Ersetzen Sie dazu --file endpoints.json durch --data gefolgt von der JSON-Zeichenfolge.)
$ rtapi --file endpoints.json --output report.pdf
  1. Um die ASCII-formatierte Tabelle mit Metriken im Terminal anzuzeigen, verwenden Sie das Flag „--print“ anstelle des Flags „--output“ (oder zusätzlich dazu).
$ rtapi --file endpoints.json --print

Den PDF-Bericht interpretieren

Der von rtapi generierte PDF-Bericht enthält ein HDR-Histogramm der Antwortlatenz wie das folgende (von einem NGINX Plus-API-Gateway, das mithilfe des NGINX Controller API Management Module konfiguriert wurde). Die Y-Achse zeigt die Latenz in Millisekunden und die X-Achse den Anteil der Aufrufe, die in weniger als einer bestimmten Latenz verarbeitet wurden, ausgedrückt als Perzentil. (Im folgenden Beispiel haben wir die Y-Achse aus Platzgründen gestaucht.)

Um die Ergebnisse für Ihre API hervorzuheben, schneiden sich die gestrichelten, parallel zu den Achsen verlaufenden Linien an dem Punkt, der die gemessene Latenz Ihrer API beim 99. Perzentil angibt (99 % im Diagramm). Damit Ihre API als echtzeitfähig gilt, muss die Latenz am Schnittpunkt weniger als 30 ms betragen.

Wie kann NGINX helfen?

Liegt die Latenz Ihrer API unter 30 ms?

Wenn es Ihnen wie vielen Unternehmen geht, mit denen wir sprechen, ist das wahrscheinlich nicht der Fall. Bei vielen API-Gateway- und API-Management-Lösungen sind Latenzzeiten von 100 ms üblich, und selbst 500 ms sind keine Seltenheit.

Wir können Ihnen helfen, die Performance Ihrer APIs zu verbessern – NGINX und NGINX Plus sind das schnellste API-Gateway der Branche und ermöglichen Ihnen zusammen mit NGINX Controller, API-Aufrufe in weniger als 30 ms weiterzuleiten, zu authentifizieren, abzusichern, zu steuern und zwischenzuspeichern. Erfahren Sie mehr, sprechen Sie mit einem NGINX-Experten und entdecken Sie unter nginx.com/real-time-api, wie NGINX Sie auf Ihrem Weg zu Echtzeit-APIs unterstützen kann.


Teilen

Über den Autor

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.