API-Lasttest-Tutorial: Anfängerleitfaden

Was ist API-Lasttest?

API-Lasttesting ist der Prozess der Bewertung der Leistung und Skalierbarkeit einer Application Programming Interface (API) unter simuliertem starkem Datenverkehr. Es überprüft, wie gut eine API erhöhte Anforderungslevels, langanhaltende Aktivitäten und umfassendere Testbereiche bewältigt, die von einzelnen Endpunkten bis hin zu kompletten End-to-End-Workflows reichen. Das Ziel ist es, zu bestätigen, dass Ihre API erwarteten Verkehrslevels zuverlässig bewältigen kann und gleichzeitig eine konsistente Benutzererfahrung liefert.

Beim API-Lasttest sammeln Sie Leistungsmetriken wie Antwortzeiten, Latenz, Durchsatz und den allgemeinen Zustand der API unter Stress. Diese Messungen bestätigen, ob Ihre Website oder Anwendung auch bei Spitzenbelastungen eine reibungslose Leistung aufrechterhalten kann.

API-Lasttests können je nach Zielen Ihres Testprozesses auf verschiedene Weisen durchgeführt werden. Vom Stresstest zur Bestimmung von Bruchpunkten bis zum Dauertest für langanhaltende Nutzung bietet jeder Testtyp unterschiedliche Einblicke in die API-Leistung unter bestimmten Bedingungen. Moderne Anwendungen verlassen sich auf mehrere APIs, die zusammenarbeiten, was es wichtig macht, das Verhalten dieser Dienste bei gleichzeitiger Nutzung zu testen.

Da Organisationen Microservices-Architekturen und API-first-Entwicklung übernehmen, ist API-Lasttesting noch kritischer geworden. Moderne Anwendungen nutzen dutzende oder sogar hunderte von APIs, die gleichzeitig kommunizieren, was Leistungstests für die Aufrechterhaltung von Zuverlässigkeit und Skalierbarkeit unverzichtbar macht.

API-Leistungstest

API-Leistungstests messen, wie sich eine API unter einem definierten Verkehrslevel verhält: wie schnell sie antwortet, wie viel Arbeit sie erledigt und wie viel dieser Arbeit fehlschlägt. Lasttest ist eine Fragestellung innerhalb dieser Disziplin – was bei dem erwarteten Traffic passiert. Der Rest der Kategorie befasst sich damit, was passiert, wenn der Verkehr plötzlich stark ansteigt oder nie aufhört.

Es gibt vier Testarten in dieser Kategorie, die jeweils eine andere Frage mit einer anderen Metrik beantworten.

• Lasttest hält Ihre API auf dem erwarteten Verkehrslevel und fragt, ob die Antwortzeiten innerhalb der Ziele bleiben. Die Metrik ist die 90. Perzentil-Antwortzeit bei der angestrebten gleichzeitigen Nutzerzahl, genannt p90, und nicht der Durchschnitt.
• Stresstest übersteigt das erwartete Level, bis etwas bricht. Die Metrik ist die gleichzeitige Nutzeranzahl, bei der die Fehlerquote zu steigen beginnt, die angibt, wie viel Spielraum über dem normalen Verkehr liegt. Lasttest vs Stresstest erklärt den Unterschied ausführlicher.
• Spike-Test springt in Sekunden von niedrigem zu hohem Verkehr, statt langsam zu steigen. Die Metrik ist die Erholungszeit: wie lange nach dem Spike die Antwortzeiten wieder das Ausgangsniveau erreichen. Autoskalierungsgruppen und Verbindungspools scheitern oft an diesem Test, obwohl sie einen allmählichen Anstieg bestehen.
• Dauertest hält eine moderate Last über Stunden. Die Metrik ist die Drift, also eine stetig steigende Antwortzeit oder Speichernutzung über einen langen Zeitraum. Verbindungslecks und ungebremste Caches zeigen sich nur bei diesem Test.

Die gleichen vier Testarten, dargestellt als gleichzeitige Nutzer über die Zeit.

Antwortzeit, Durchsatz und Fehlerquote werden in allen vier Tests gemessen. Was sich ändert, ist die zuerst zu betrachtende Metrik: Antwortzeit im Lasttest, Fehlerquote im Stresstest, die Form der Antwortzeitkurve nach einem Spike und die Steigung über den gesamten Verlauf im Dauertest.

Nur Lasttests durchzuführen ist eine häufige Lücke. Ein Dienst kann einen sauberen Anstieg bis 200 gleichzeitige Nutzer schaffen und dennoch bei einem Marketing-E-Mail-Event, das dieselben 200 Nutzer in vier Sekunden anfordert, zusammenbrechen oder über sechs Stunden Speicher lecken und deshalb einen nächtlichen Neustart brauchen.

Warum API-Lasttest kritisch ist

API-Lasttests stellen sicher, dass Ihre Anwendung unter hoher Last reibungslos läuft. Da APIs das Rückgrat moderner Apps sind, wirkt sich jede Verlangsamung oder Ausfall direkt auf die Benutzererfahrung aus. Lasttests decken Engpässe und Leistungsgrenzen auf, die Sie optimieren müssen, um Abstürze während Spitzenzeiten zu verhindern und Ihre App zuverlässig unabhängig von der Nachfrage zu halten.

Vorteile von API-Lasttests und warum Sie sie durchführen sollten

APIs sind das Rückgrat der meisten modernen Software, daher lohnt sich die Mühe des Lasttests. Er zeigt, wie Leistung, Skalierbarkeit und Zuverlässigkeit unter gleichzeitiger Nutzung gehalten werden, und bestätigt, dass die API Ihre Service Level Agreements erfüllt.

API-Ausfallkosten minimieren

API-Leistungsprobleme vor der Bereitstellung zu erkennen, kostet eine Organisation deutlich weniger als die Behebung von API-Ausfällen in der Produktion. Lasttests finden Codefehler, die unter erwarteter oder unerwarteter Belastung zu Leistungseinbußen führen, und offenbaren Implementierungsfehler, die sonst schwer reproduzierbar sind.

API-Ausfallzeiten minimieren und abmildern

API-Lasttests zeigen die Kapazität der API, Benutzeranfragen ohne Absturz zu bewältigen, was Ausfallzeiten verhindert. Sie reduzieren auch die Wahrscheinlichkeit von Ausfällen, indem sie die Anfragen identifizieren und isolieren, die Optimierungsbedarf haben, sodass Ihre Ressourcen dort eingesetzt werden, wo der Verkehr tatsächlich problematisch ist.

Ihre API-Infrastruktur verbessern

API-Lasttests bestimmen die geeignete Infrastruktur, indem sie das Volumen der API-Anfragen bei verschiedenen Nutzungsszenarien bewerten und die maximale Anzahl gleichzeitiger Anfragen ermitteln, die ein einzelner Endpunkt bewältigen kann. Mit dieser Zahl können Ihre Teams erwartete Verkehrsspitzen planen.

API-Leistung und Kundenzufriedenheit verbessern

API-Entwicklung ist schwierig, da viele Endpunkte und hohe Nutzererwartungen existieren. Ihre APIs könnten unter verzögerten Antwortzeiten, Latenzproblemen und Durchsatzgrenzen leiden. Lasttests erkennen diese Engpässe schneller und ermöglichen deren Behebung vor dem Produktionsstart.

Wann man API-Lasttests durchführt

API-Lasttests lohnen sich in verschiedenen Phasen des Softwareentwicklungszyklus. Sie helfen in der Entwicklung, Leistungsengpässe früh zu erkennen und zu bestätigen, dass Ihre APIs erwartete Lasten bewältigen und sich unter Belastung vorhersehbar verhalten. Lasttests sollten auch vor dem Produktionsstart durchgeführt werden, um Skalierbarkeit und Zuverlässigkeit in einer simulierten Produktionsumgebung zu validieren. Immer wenn signifikante Änderungen an APIs oder deren zugrundeliegender Infrastruktur stattfinden, bewerten Lasttests die Auswirkungen und bestätigen, dass neue Implementierungen die Leistungserwartungen erfüllen. Regelmäßige, periodische Lasttests sind ebenfalls ratsam, um Leistungsverfall zu erkennen, bevor er Endbenutzer beeinträchtigt.

Wie man APIs belastet

Ein API-Lasttest erfolgt in acht Schritten: Definieren des Ziels als Zahl, Auswahl des Testtyps, Konfiguration der Anfrage, Hinzufügen von Validierungen, Festlegen der Lastkurve, Auswahl der Lastquelle, Durchführung des Tests und Auswertung des Berichts. Die folgende Schritt-für-Schritt-Anleitung nutzt api.restful-api.dev/objects, eine kostenlose REST-API ohne Schlüssel. Es handelt sich um einen öffentlichen Dienst, daher sollten Testläufe mit ca. 25 gleichzeitigen Nutzern erfolgen und dieselbe Konfiguration für Ihre eigenen Endpunkte verwendet werden, um Zahlen bei 200 Nutzern zu erzielen.

Schritt 1: Schreiben Sie auf, was Sie herausfinden möchten

Formulieren Sie Ihr Ziel als überprüfbare Zahlenangabe. „Sehen, ob die API schnell ist“ kann man nicht bestehen oder nicht bestehen lassen; dieses Beispiel schon:

Bei 200 gleichzeitigen Nutzern, gehalten für 10 Minuten, liefert GET /objects eine Antwortzeit im 90. Perzentil unter 400 ms bei einer Fehlerquote unter 1%.

Vier Dinge machen das nutzbar: eine Nutzer-Anzahl, eine Dauer, der Endpunkt und eine Schwelle, die auf einem Perzentil statt einem Durchschnitt basiert. Durchschnitte verschleiern langsame Anfragen. Wenn 95 Requests in 80 ms zurückkommen und 5 sechseinhalb Sekunden brauchen, liegt der Durchschnitt komfortabel bei 376 ms, aber 5% Ihrer Nutzer warteten sechs Sekunden.

Nehmen Sie die Schwelle von einem bereits vorhandenen Budget oder führen Sie einen Lauf bei niedriger Last durch und nutzen das als Basis. Sie benötigen außerdem die URL, die Methode, benötigte Header, einen Body, falls die Methode einen erfordert, und Zugangsdaten. Hier: https://api.restful-api.dev/objects, GET, keine Authentifizierung.

Schritt 2: Wählen Sie den Testtyp

LoadView fragt zuerst nach dem Testtyp, der den Rest der Einrichtung prägt. Optionen sind Real Browser (Webanwendung), HTTP/S, SOAP, Rest WEB API, Postman (Collection), JMeter, Selenium, Streaming Media und WebSocket.

Wohin Sie den Test richten, bestimmt den Typ.

Für einen JSON-Endpunkt wählen Sie Rest WEB API. Es prüft Verfügbarkeit, Leistung, zurückgelieferte Daten und Authentifizierung unter Last mit Feldern für Header, Body und Validierung. Die anderen passen zu spezifischen Fällen:

• HTTP/S für gleichzeitige Anfragen an eine URL, wenn nur die Antwort des Servers wichtig ist.
• SOAP für WSDL-Dienste, bei denen die Anfrage ein XML-Umschlag ist.
• Postman (Collection), wenn die Anfragen bereits in einer Sammlung vorliegen: exportieren und hochladen, wie das Postman Collection Lasttest-Tutorial beschreibt. JMeter macht das Gleiche für einen JMX-Plan.

Schritt 3: Konfigurieren Sie die Anfrage

Geben Sie die vollständige URL inklusive Schema ein und setzen Sie dann die Methode im Feld Request Type: https://api.restful-api.dev/objects mit GET.

Vier Felder, zwei mit Fallstricken.

Markieren Sie als Fehler, wenn die Antwortzeit überschritten wird setzt, wie viele Sekunden LoadView wartet, bevor ein Fehler protokolliert wird, und das ist wichtiger als es scheint: Bei einem hohen Standardwert zählt eine 30-Sekunden-Anfrage noch als Erfolg. Setzen Sie es dort, wo ein Nutzer aufgegeben hätte, hier 5 Sekunden.

Header kommen in den Bereich Headers als Name-Wert-Paare.

Bei POST oder PUT kommt die Nutzlast in den Bereich Body, in älterer Dokumentation Post Data genannt. Fügen Sie JSON ein, LoadView parst es, fordert Sie auf, einen Content-Type-Header zu wählen, und fügt diesen Header automatisch den Headers hinzu:

{
  "name": "LoadView Test Object",
  "data": {
    "year": 2026,
    "price": 1849.99,
    "CPU model": "Intel Core i9",
    "Hard disk size": "1 TB"
  }
}

Zugangsdaten kommen in den Bereich Basic Authentication. Token-basierte Authentifizierung ist zwei Anfragen statt einer Einstellung, da Sie das Token erst abrufen müssen, bevor Sie es verwenden können. LoadView dokumentiert dieses Muster für OAuth 2.0-basierte APIs: eine Tokenanforderung, dann eine Ressourcennachfrage mit dem Ergebnis.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Fügen Sie die zweite Anfrage mit Add Target hinzu; die Anfragen werden in der Sidebar in der Reihenfolge ausgeführt, in der sie erscheinen. Um das Token zu übertragen, wandeln Sie den benötigten Parameter in einen Context Parameter um, der für URL, Header, Body und Skripte funktioniert.

Ein Token-Fluss sind zwei Anfragen, keine einzelne Einstellung.

Schritt 4: Validierung hinzufügen

Ein Test, der nur prüft, ob Bytes zurückkamen, meldet einen sauberen Lauf, während Ihre API 500-Fehler liefert. Schnelle Fehler sind die schnellsten Antworten in jedem Test, prüfen Sie daher zwei Dinge.

Erwartete Antwortcodes deklariert, welche Statuscodes als Erfolg zählen; alles andere wird als Fehler protokolliert. Setzen Sie für diesen GET auf 200. Statuscode-Semantik stammt von RFC 9110, und die Falle ist POST: Viele APIs antworten auf eine erfolgreiche Erstellung mit 201, daher benötigt eine Anfrage, die ein Objekt erstellt, 200, 201 und nicht nur 200.

Nur das dritte Panel beweist, dass die Anfrage tat, was Sie wollten.

Inhaltsvalidierung prüft den Antwortkörper auf von Ihnen vorgegebene Schlüsselwörter, kombiniert mit logischen Ausdrücken, bei denen & UND, | ODER und ! NICHT bedeutet:

{["Apple MacBook Pro 16"&"CPU model"]}

Wählen Sie ein Schlüsselwort, das nur bei Erfolg vorkommt. Ein Feldname, der auch im Fehler-Umschlag der API erscheint, validiert nichts.

Schritt 5: Lastkurve einstellen

LoadView bietet drei Lastkurvenoptionen. Diese Anleitung verwendet Load Step Curve, die auf die Frage antwortet: “Wie verändern sich die Antwortzeiten, während Nutzer dazukommen”. Dieser Lauf startet bei 5 gleichzeitigen Nutzern, steigt in 6 Minuten auf 25 an, hält diese Last 5 Minuten und fährt danach in 2 Minuten zurück. Bei Ihrem eigenen Endpunkt: Start bei 10, Anstieg auf 200 in 10 Minuten, Halten 10, Ramp-down 3. Die Haltezeit ist der Teil, den Menschen oft kürzen und der wichtig ist: Die Rampe zeigt, wann es begann, sich zu verschlechtern, das Halten, ob es dabei bleibt.

Die Kurve, die dieser Lauf nutzte, mit Beschriftung jedes Abschnitts.

Goal-Based Curve nimmt einen angestrebten Durchsatz und passt virtuelle Nutzer an, um ihn zu erreichen – passend für Anforderungen, die als Transaktionen pro Minute formuliert sind. Dynamic Adjustable Curve lässt Sie die Nutzerzahl während des Tests manuell ändern, nützlich beim Infrastruktur-Ausbau, während Sie die Auswirkungen im gleichen Fenster beobachten.

Schritt 6: Wählen Sie geografische Regionen aus

Load-Injektoren starten in über 40 Zonen in Nordamerika, Südamerika, Europa und APAC. Geographie ist hier keine Dekoration: Jede Entfernung von 1.000 Meilen zwischen Client und Server fügt Round-Trip-Latenz hinzu, die keine Anwendungsoptimierung entfernt, und ein TLS-Handshake bezahlt diese Kosten mehrmals.

Dieser Lauf verwendete eine einzelne US-East-Zone, was das Anwendungsverhalten von der Netzdistanz trennt. Fügen Sie die Zonen hinzu, aus denen Ihre Nutzer kommen, sobald Sie diese Basislinie haben: Wenn Ihre API in us-east-1 ist und ein Viertel Ihres Verkehrs aus Deutschland kommt, ist die Zahl für Frankfurt der Wert, den diese Nutzer erhalten. Das geografisch verteilte Lastinjektor-Netzwerk wird verwaltet, sodass nichts dimensioniert werden muss.

Der gleiche Endpunkt, aus drei Entfernungen gemessen.

Schritt 7: Führen Sie den Test aus und lesen Sie den Bericht

LoadView kalibriert vor dem Lauf, um zu bestimmen, wie viele Injektor-Server benötigt werden. Beobachten Sie die ersten zwei Minuten: Antwortzeiten, die bereits bei 5 Nutzern steigen, deuten auf ein Setup-Problem und nicht auf ein API-Problem hin, daher stoppen und beheben Sie das lieber, bevor Sie für die ganze Kurve zahlen. Lassen Sie den Test danach laufen. Ein Neustart eines Dienstes während des Laufs erzeugt ein Diagramm, das niemand interpretieren kann.

Der Bericht öffnet sich auf dem Zusammenfassung-Tab: eine Übersicht erfolgreicher Sitzungen gegenüber Sitzungen mit Fehlern, dann folgen die Diagramme. Lesen Sie sie in dieser Reihenfolge.

Ausführungsplan kommt zuerst und wird am häufigsten übersprungen. Er zeigt tatsächliche virtuelle Nutzer gegen erwartete und maximale virtuelle Nutzer. Wenn die tatsächliche Linie der erwarteten folgt, dann wurde die Last, die Sie anzuwenden glaubten, auch wirklich angelegt. Bleibt sie darunter, beschreibt der Rest des Berichts einen Test, der nie stattfand.

Vier Diagramme, vier Fragen, in der Reihenfolge, in der sie gestellt werden sollten.

Antwortzeit zeigt die durchschnittliche Transaktionsdauer und das 90. Perzentil gemeinsam. Lesen Sie die Lücke zwischen den Linien, nicht nur deren Höhe. Ein p90, das sich vom Durchschnitt entfernt, bedeutet, dass sich ein langsamer Schwanz bildet: eine Warteschlange füllt sich, ein Verbindungspool ist am Limit, ein Cache beginnt zu verpassen. Die Lücke öffnet sich, bevor der Durchschnitt steigt, was es zum frühen Signal macht.

Warum das Perzentil die Frühwarnung ist und der Durchschnitt die Späte.

Gestartete Sitzungen vergleicht Gesamtanzahl der Sitzungen gegen erfolgreiche und fehlgeschlagene. Das Verschlechtern der Antwortzeit unter Last ist normal und meist akzeptabel; das Scheitern von Anfragen nicht. Filtern Sie im Tab Sitzungen nach dem Status „Fehlgeschlagen“ für einzelne Antworten inklusive Statuscode und Serverantwort.

Lastinjektor-Auslastung ist der Plausibilitäts-Check: Hohe Auslastung der Injektoren neben einem langsamen Ziel deutet darauf hin, dass Sie die Testinfrastruktur messen und nicht die API. Drei Messwerte sollten zum Handeln bewegen:

• Fehlerquote steigt vor der Antwortzeit. Etwas lehnt Verbindungen ab statt sie zu warten. Prüfen Sie zuerst Verbindungsgrenzen, Arbeitsprozesse und Ratenbegrenzung.
• Das 90. Perzentil steigt, während der Durchschnitt stabil bleibt. Manche Anfragen nehmen einen langsamen Pfad: Cache-Misses, eine Abfrage ohne Index, eine verzögerte Abhängigkeit.
• Durchschnitt und p90 steigen proportional mit den Nutzern. Auslastung, der am leichtesten zu planende Fall. Notieren Sie die gleichzeitige Nutzerzahl, bei der Sie die Schwelle überschreiten, und behandeln Sie sie als Obergrenze.

Die gleichen drei Messwerte und wohin jeder Sie führt.

Latenz, Verkehr, Fehler und Auslastung sind die vier Signale, die das SRE-Buch von Google für ein benutzerorientiertes System empfiehlt. Ein Lasttest misst die ersten drei von außen; beobachten Sie die Auslastung auf dem Server und denken Sie daran, dass die meisten Systeme schon vor 100% Auslastung stark nachlassen. Für mehr zum Bericht siehe Wie man Lasttestergebnisse mit LoadView analysiert.

Schritt 8: Was ging schief

Der POST-Test maß eigentlich ein GET. Der Anfragetyp war auf POST gesetzt und der Endpunkt korrekt, aber der Body war noch leer und LoadView wechselt beim Speichern bei POST, PUT oder PATCH ohne Anfrageparameter zurück auf GET. Es gibt keine Warnung danach. Der Test wurde sauber ausgeführt und meldete gute Zahlen für ein Lesen an einem Endpunkt, der eigentlich als Schreib-Endpunkt gedacht ist. Füllen Sie den Body vor dem Speichern aus, öffnen Sie dann die Anfrage erneut und bestätigen Sie, dass die Methode hält.

Die zweite Falle ist subtiler. Die Demo-API antwortet auf eine erfolgreiche Erstellung mit 200, viele APIs aber mit 201. Senden Sie eine Anfrage manuell und lesen Sie den Statuscode, bevor Sie erwartete Antwortcodes eintragen. Eine öffentliche Demo-API limitiert auch die Rate; wenn die Fehlerquote bei einer Last steigt, die Ihre Infrastruktur locker schafft, prüfen Sie, ob Sie gedrosselt werden anstatt eine Auslastung zu erleben.

LoadViews eigene Dokumentation beschreibt, dass mehrstufige Anfragesequenzen im Rest WEB API-Test umständlich zu konfigurieren sein können, und verweist für komplexe Abläufe auf Postman. Wenn das Verkettung von vier Anfragen zu einem Projekt wird, ist das der Punkt zum Ausstieg.

Best Practices für API-Lasttests

Fünf Einstellungen beeinflussen Ihre Zahlen am meisten: Denkzeit, Testdaten, die Testumgebung, die Aufwärmphase und wie oft Sie den Lauf wiederholen. Allgemeine Gewohnheiten zuerst:

• Testen Sie in einer dedizierten Umgebung, aber mit produktionsnahen Daten.
• Definieren Sie Ihre Benchmarks im Voraus. Service Level Agreements geben Ihnen Ziele zum Testen.
• Beginnen Sie früh und testen Sie oft, damit Probleme auftauchen, bevor Ihre APIs live gehen.

Diese vier sind leicht zu akzeptieren, aber ohne Details schwer umzusetzen. So sehen sie in Einstellungen aus.

Denkzeit an das Aufrufverhalten anpassen

Denkzeit ist die Pause zwischen Anfragen, kontrolliert durch das User Behavior Profile. Minimale Pausen führen den Test mit maximaler Geschwindigkeit aus, was Limits schnell findet und eine Anfragefrequenz produziert, die keine reale Nutzergruppe erreicht. Realistische Pausen geben Ihnen eine Kapazitätszahl, mit der Sie planen können.

Was passt, hängt vom Aufrufer ab. Eine API, die von einer mobilen App zwischen Bildschirmtipps angerufen wird, hat natürlich Sekunden Denkzeit, modellieren Sie das. Eine API, die von einem engen Dienst in einer Schleife aufgerufen wird, hat effektiv keine Denkzeit. Zu großzügige Pausen sind die häufigste Fehlerquelle, wenn ein Lasttest eine Kapazität meldet, die das System tatsächlich nicht hat.

Jeder virtuellen Nutzer eigene Testdaten geben

200 virtuelle Nutzer, die /objects/7 anfragen, bedienen sich nach der ersten Anfrage aus dem Cache, und Ihre Zahlen beschreiben den Cache. Variieren Sie den Bezeichner, sodass jeder Nutzer einen anderen Datensatz berührt. Das Prepare Script-Feld nimmt C# entgegen. Generieren Sie je Sitzung einen eindeutigen Wert und verwenden Sie ihn im Request Body mittels Razor-Syntax:

context.Guid = Guid.NewGuid().ToString();
context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z";
ProcessPostDataByRazor(currentTask);

Der Body referenziert diese als @Model["Guid"] und @Model["CurrentTime"]. Wenn Ihr Test Datensätze erstellt, planen Sie, wie diese wieder gelöscht werden. Ein Dauertest, der sechs Stunden schreibt, hinterlässt eine Tabelle, die Ihr nächster Test durchlesen muss.

Entscheiden Sie vor dem Test, was Sie testen

Tests an der Produktion liefern die einzigen glaubwürdigen Antworten, bergen aber Risiken für Ihre Kunden. Tests an Staging sind sicher, liefern aber nur Aussagen über Staging. Der praktikable Mittelweg ist eine Staging-Umgebung, die Produktion bei den drei Leistungsbeeinflussenden Faktoren abbildet: Instanzgrößen, Datenbankzeilenanzahl und Cache-Konfiguration. Eine Staging-Datenbank mit 10.000 Zeilen reproduziert nicht den Abfrageplan, den Produktion mit 40 Millionen wählt. Wenn diese Faktoren nicht übereinstimmen, notieren Sie vor dem Lauf deren Unterschiede, damit Sie wissen, in welche Richtung Ihre Ergebnisse verzerrt sind.

Vor dem Messen aufwärmen

Die erste Minute eines Laufs misst kalte Caches, leere Verbindungspools und nicht JIT-kompilierten Code. Diese Zahlen sind real, beantworten aber eine andere Frage als die von Ihnen gestellte. Eine Rampe behandelt das von selbst, was ein weiterer Grund für die Load Step Curve gegenüber einem flachen Beginn ist. Starten Sie flach, verwerten Sie die ersten 60 bis 120 Sekunden nicht und bleiben Sie dabei konsistent: Einen warmen Lauf mit einem kalten über Releases zu vergleichen ergibt Regressionen, die nicht existieren.

Führen Sie denselben Test dreimal aus

Ein einzelner Lauf ist eine Anekdote. Geteilte Infrastruktur, laute Nachbarn und zufällig aktive Hintergrundjobs verändern ein Ergebnis mehr als die Veränderung, die Sie messen.

Führen Sie dieselbe Konfiguration dreimal aus und vergleichen Sie das 90. Perzentil über alle drei. Eine Streuung unter ca. 10 % gibt Ihnen eine verlässliche Zahl. Größer heißt, Ihre Umgebung ist zu laut zum Messen und das Beheben kommt zuerst. Wenn die Zahl stabil ist, wird sie zur Basis für spätere Vergleiche.

API-Lasttest-Automatisierung in CI/CD

Automatisieren Sie API-Lasttests, indem Sie Tests aus Ihrer Pipeline auslösen und den Build fehlschlagen lassen, wenn Schwellwerte nicht eingehalten werden. LoadView bietet CI/CD-Integrationen für Azure DevOps, Jenkins und CircleCI, die genau das tun. Die meisten Teams hören nach dem ersten erfolgreichen Lauf auf, obwohl eine Basislinie sich nur durch häufige Tests lohnt.

Teilen Sie die Arbeit nach Kosten auf. Ein kurzer Check an ein oder zwei Endpunkten gehört zu jedem Merge in den Hauptbranch: geringe Gleichzeitigkeit, wenige Minuten, genug, um eine verlorene Index-Abfrage zu finden. Die volle Lastkurve gehört zu einem Release-Kandidaten. 200 gleichzeitige Nutzer bei jedem Commit zu testen, kostet Geld für Fragen, die Sie früh am Tag schon beantwortet haben.

Ein kurzer Check bei jedem Merge, die volle Kurve beim Release-Kandidaten.

Das Gate selbst ist der Failed Sessions Threshold: Legen Sie den Prozentsatz fehlgeschlagener Sitzungen fest, den Sie tolerieren, und der Build schlägt fehl, wenn ein Test diesen überschreitet.

Diese Schwelle gilt für Fehler, nicht für Langsamkeit. Ein Build, bei dem jede Sitzung bei dreifacher p90 erfolgreich war, besteht ein fehlgeschlagener-Sitzungs-Gate sauber, daher benötigt die Antwortzeit eine eigene Überprüfung. Ziehen Sie das p90, vergleichen Sie es mit der gespeicherten Basislinie und legen Sie im Voraus fest, was eine Regression ist. 20% über Basis sind ein vernünftiger Anfang, später anpassbar je nach Umgebungsrauschen.

Bewahren Sie die Testdefinition in der Versionskontrolle auf, wo das Tool es erlaubt: Eine JMX-Datei oder Postman-Collection im Repo ändert sich, wenn sich der Code ändert, den sie testet. Und beheben Sie eine laute Umgebung, bevor Sie sie als Gate einsetzen, da ein Pipeline-Gate, das Builds zufällig scheitern lässt, in ein bis zwei Wochen abgeschaltet wird – dann haben Sie weder Gate noch Gewohnheit.

Vergleich der API-Lasttest-Tools

Apache JMeter, Postman, Grafana k6, SoapUI und LoadView decken den Großteil der API-Lasttests ab, und sie konkurrieren nicht um denselben Job. Wählen Sie basierend darauf, woher die Last kommen muss und wo der Test laufen soll, nicht nach Funktionsumfang.

1) LoadView setzt sich durch dank verwalteter Injektoren, die Tests aus 40+ Zonen zu einer Konfigurationsfrage machen statt einem Beschaffungsprojekt, und durch Real Browser Tests parallel zu API-Tests. Es importiert JMX-Dateien und Postman-Collections, so dass bestehende Testpläne erhalten bleiben. LoadView bietet On-Demand-, Abonnement- und Enterprise-Pläne an, während ein leichter Test, der bei jedem Commit läuft, in Ihrer Pipeline besser zu einem CLI-Tool gehört.

2) Apache JMeter ist die fähigste kostenlose Option mit der umfangreichsten Plugin-Community, die über HTTP hinaus Datenbanken und Nachrichtenwarteschlangen abdeckt. Die Kosten sind nicht die Lizenz, sondern der Betrieb: Sie stellen Lastgeneratoren bereit und überwachen sie, und Last aus fünf Ländern bedeutet Maschinen in fünf Ländern.

3) Postman hat den kürzesten Weg von einer vorhandenen Anfrage zu einer Lastzahl, indem es die für Funktionstests gebaute Sammlung nutzt, lokal oder in der Postman-Cloud ausgeführt. Für einen Entwickler, der vor einem Pull-Request einen Endpunkt checken will, ist es unschlagbar schnell. Es ist ein Tool für die Entwicklungszeit, kein Kapazitätsplanungstool, und Postman positioniert es entsprechend.

4) Grafana k6 ist die beste Wahl, wenn Leistungstests versioniert gehören. Tests sind JavaScript, werden überprüft, verglichen und laufen im gleichen Pipeline-Kontext wie der übrige Code, mit Schwellwerten, die Builds wie Unit-Tests fehlschlagen lassen. Wenn Sie bei jedem Pull Request prüfen wollen, ist k6 die bessere Voreinstellung als LoadView, und das sollte man klar sagen.

5) SoapUI deckt funktional, Sicherheits-, Last- und Mocking-Tests in einem Open-Source-Tool für REST, SOAP und GraphQL ab. Sein Vorteil ist Wiederverwendung: Ein funktionaler Testfall wird ohne Neuaufbau zu einem Lasttest, was in SOAP-lastigen Umgebungen wichtig ist. ReadyAPI ist die kommerzielle Version von SmartBear mit größerem Lasttest-Modul.

Wo man anfängt

Wählen Sie den einzelnen Endpunkt, der am meisten schadet, wenn er langsam wird, meist Login, Suche oder Checkout. Führen Sie einen Rest WEB API-Test auf Ihre erwartete Höchstlast mit einer Rampe, halten Sie ihn zehn Minuten und führen Sie ihn dreimal von einem Standort aus. Das ist an einem Nachmittag eine Basislinie. Teams stocken beim Versuch, das ganze System auf einmal zu modellieren.

API-Lasttest FAQ

Die unten stehenden Fragen tauchen auf, sobald ein Team begonnen hat, API-Lasttests durchzuführen. Jede Antwort steht für sich.

API-Lasttests mit LoadView durchführen

API-Lasttests mit LoadView können so einfach sein, dass Sie ein Skript erstellen, das mehrere API-Aufrufe hintereinander sendet, und die Zahl der gleichzeitigen Nutzer bis zu den erwarteten Limits skaliert. Die Skripte sind wiederverwendbar und können das System während der gesamten Dienstzeit überwachen.

LoadView API-Lasttests unterstützen RESTful APIs inklusive JSON und XML, SOAP und Web APIs mit Authentifizierung oder mehrstufiger Ausführung. Je nach Anforderungen Ihres Tests stehen mehrere Lastkurven zur Verfügung.

Es gibt drei Lastkurven: Load Step Curve für eine vorgegebene Nutzerzahl über eine bestimmte Dauer, Goal-based Curve, die automatisch einen geforderten Transaktionssatz erreicht, und Dynamic Adjustable Curve, mit der Sie während eines Tests die Last manuell verändern können.

LoadView verteilt die Last auf über 40 geografische Regionen in beliebiger Aufteilung, wobei die Auswahl der Regionen nahe Ihren Nutzern die realistischste Emulation erzeugt.