Wie wir GraphQL-Antwortzeiten messen

"Welche Antwortzeiten können wir von Ihrer GraphQL API erwarten?" 

Dies ist wahrscheinlich eine der am häufigsten gestellten Fragen, die wir bei Marketplacer im Zusammenhang mit unserer GraphQL-API erhalten. Es ist eine sehr vernünftige Frage, und wir verstehen, warum unsere Kunden sie stellen, aber sie ist nicht immer so einfach zu beantworten...

In diesem Artikel stellen wir einen der Ansätze vor, die wir bei Marketplacer für das Benchmarking von GraphQL-API-Antwortzeiten verwendet haben.

Doch zunächst einige Hintergrundinformationen...

Das "Problem" mit GraphQL...

Das gesamte Wertversprechen des GraphQL-Designmusters (für mich jedenfalls) ist das:

• Es vermeidet übermäßiges Abrufen
• Es wird vermieden, dass zu wenig abgerufen wird.

Oder, um es noch positiver auszudrücken, Sie erhalten genau die Antwort auf die Nutzlast, die Sie wünschen. Die Möglichkeit, Abfragen zu schreiben und die Nutzlast genau auf Ihre Bedürfnisse abzustimmen, macht das Angebot so attraktiv. Um zu veranschaulichen, was ich meine, lassen Sie uns einen Blick auf eine der Abfragen werfen, die wir bei Marketplacer anbieten: advertSearch.

Eine "Anzeige" in Marketplacer ist eigentlich nur ein ProduktAber aus verschiedenen Gründen, auf die ich hier nicht eingehen werde, nennen wir sie in der Marketplacer GraphQL API "Anzeigen".

AdvertSearch ermöglicht es den Nutzern unserer GraphQL-API, Produkte, die in Marketplacer gehostet werden, in jedes vorgelagerte System zu ziehen, das sie benötigt. Zwei typische Anwendungsfälle wären:

• So geben Sie eine Liste von Produkten auf einer Suchergebnisseite wieder
• So zeigen Sie eine einzelne Produktdetailseite (oder "PDP" in der Welt von eCom) an

Diese 2 Verwendungszwecke haben unterschiedliche Merkmale:

• Die 1. erfordert mehrere Objekte, aber jedes mit einer "kleinen" Menge an Daten
• Die 2. erfordert nur 1 Objekt, aber mit einer "großen" Menge an Daten

In diesen beiden Fällen können Sie die advertSearch Abfrage verwenden, um diese Daten zu erhalten, aber ist es sicher anzunehmen, dass beide Abfragen ähnliche Antwortzeiten haben würden? Äh, nein, das wäre nicht der Fall...

Dieses Rätsel bringt uns wirklich zum Ausgangspunkt zurück, nämlich zu der Frage: "Welche Antwortzeiten können wir von Ihrer GraphQL-API erwarten?" Es gibt nicht wirklich 1 Antwort...

Abfrage-Profile

Um zu versuchen, die Frage nach den Antwortzeiten zu beantworten, haben wir eine Reihe von "Abfrageprofilen" entworfen, die versuchen, eine Reihe von häufigen Anwendungsfällen abzudecken.

Anschließend führen wir jedes dieser Abfrageprofile in regelmäßigen Abständen mit K6(ein sehr beliebtes Lasttest-Framework) und erfassen die resultierenden Daten für die anschließende Berichterstattung. Dadurch erhalten wir nicht nur eine ziemlich gute Antwort auf die oben genannte Frage, sondern auch:

• Ermöglicht uns die Verfolgung der Antwortzeiten über einen längeren Zeitraum
• Einfaches Einführen neuer Profile, wenn unsere Kunden dies wünschen

Zu den aktuellen Merkmalen unserer Profile gehören die folgenden:

• Abfragetiefe: Wie viele Verbindungen werden in der Abfrage durchlaufen? Dies reicht von 1 aufwärts. Je "tiefer" die Abfrage ist, desto kostspieliger ist sie, was sich auf die Antwortzeiten auswirken kann
• Seitengröße: Die Anforderung von maximal 10 statt 1000 Ergebnissen pro Seite hat Auswirkungen auf die Antwortzeiten
• Filter: Wie viele Filter werden bei Suchanfragen angewendet?

Hier sind zum Beispiel 2 Suchprofile für advertSearch (wir haben viele weitere, aber das sind nur 2 extreme Beispiele):

• 1-Ebenen-Tiefe / 10 Ergebnisse pro Seite / Keine Filterung
• 2-Ebenen-Tiefe / 1000 Ergebnisse pro Seite / 1x Filter

Wie Sie sich sicher vorstellen können, ist die Antwortzeit der ersten Abfrage kürzer als die der zweiten...

Gemessene Werte

Wie bereits erwähnt, verwenden wir K6 als primäres Vehikel zur Durchführung von Tests, wobei jeder Test mit den folgenden Parametern durchgeführt wird:

• Virtuelle Benutzer (VUs): 1
• Dauer: 10s

Diese können natürlich geändert werden, aber für Benchmarking-Zwecke halten wir das für in Ordnung. Aus den Ergebnissen der einzelnen Tests werden dann die folgenden Metriken ermittelt:

• Mittlere Reaktionszeit
• Durchschnittliche Antwortzeit (die Durchschnittswerte sind nicht besonders gut, aber wir erfassen sie trotzdem)
• p(90): 90% der Anfragen sollten schneller als die angegebene Latenzzeit sein
• p(95): 95% der Anfragen sollten schneller sein als die angegebene Latenzzeit

K6 hat eine viel breitere Palette von Metriken zur Verfügung, aber auch hier wollten wir nur versuchen, eine einfache Frage auf die einfachste Weise zu beantworten...

Abschließende Überlegungen

Wie in der Einleitung erwähnt, verwenden wir einige ergänzende Ansätze zur Messung von GraphQL-Antwortzeiten; diese Technik gibt uns jedoch eine gut definierte Reihe von Tests, die Point-in-Time-Vergleiche ziemlich einfach machen.