API-Lasttests ohne Python (Locust-Alternative)

Sie möchten wissen, was mit Ihrer API passiert, wenn 80 Personen gleichzeitig zur Kasse gehen. Also öffnen Sie Locust, und das Erste, worum Sie gebeten werden, ist, eine Python-Klasse zu schreiben. Definieren Sie einen HttpUser. Dekorieren Sie Methoden mit @task. Erstellen Sie eine locustfile.py, richten Sie eine virtuelle Umgebung ein, pinnen Sie ein paar Abhängigkeiten an und finden Sie dann heraus, warum Ihr Auth-Token nicht über Anfragen hinweg wiederverwendet wird. Nichts davon ist der Test. Es ist der Eintrittspreis, bevor der Test überhaupt beginnt.

Locust ist ein gutes Tool, und dieses Code-First-Design ist der Sinn davon. Aber wenn Ihr Ziel eine direkte Antwort auf die Frage ist, ob Ihr Login-Endpunkt bei 100 gleichzeitigen Benutzern standhält, ist das Schreiben und Pflegen eines Python-Frameworks ein großer Aufwand für eine einzige Zahl. Es gibt einen schnelleren Weg, wenn die API-Anfragen, die Sie belasten möchten, bereits in einem API-Client vorhanden sind. Mit Apidog richten Sie einen Performance-Test auf ein bestehendes Testszenario aus, legen die Anzahl der virtuellen Benutzer und eine Dauer fest und lesen Durchsatz, Antwortzeit und Fehlerrate von einem Live-Diagramm ab. Keine locustfile, kein pip install, überhaupt kein Python.

Was Locust tatsächlich gut kann

Locust ist ein quelloffenes Lasttest-Tool, das in Python geschrieben ist, und es ist gut in dem, wofür es entwickelt wurde. Sie beschreiben Benutzerverhalten als Code. Ein virtueller Benutzer ist eine Python-Klasse, und die Dinge, die dieser Benutzer tut, sind Methoden, die Sie als Aufgaben kennzeichnen. Hier ist die kanonische Form einer locustfile.py:

from locust import HttpUser, task, between

class CheckoutUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def browse_products(self):
        self.client.get("/api/products")

    @task(1)
    def add_to_cart(self):
        self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})

Sie führen es mit locust -f locustfile.py aus, öffnen die Web-Benutzeroberfläche unter localhost:8089, legen eine Benutzeranzahl und eine Startrate fest und beobachten, wie die Zahlen steigen. Da das Verhalten Code ist, erhalten Sie eine echte Ausdruckskraft. Bedingte Logik, gewichtete Aufgabenverteilungen, sequentielle Benutzerpfade, benutzerdefinierte Clients für Protokolle jenseits von HTTP, gemeinsamer Zustand über Anfragen hinweg. Die Gewichtung von @task(3) gegenüber @task(1) oben bedeutet, dass das Browsen dreimal so oft stattfindet wie das Hinzufügen zum Warenkorb, was die Art von Realismus ist, die eine flache Anfrageliste nicht erfassen kann.

Locust skaliert auch horizontal. Betreiben Sie es verteilt über mehrere Worker-Prozesse oder Maschinen, und ein einzelner Master koordiniert sie, sodass Sie über das hinausgehen können, was ein einzelner Rechner generieren kann. Es ist intern ereignisgesteuert, sodass jeder Worker Tausende von gleichzeitigen Benutzern ohne einen Thread pro Benutzer, der Speicher verbraucht, halten kann. Für ein Team, das bereits in Python lebt, seine Lasttests als versionierten Code behandelt und komplexes mehrstufiges Benutzerverhalten modellieren muss, ist Locust eine starke Wahl. Nichts davon wird bestritten.

Die Kosten sind der Code. Jeder Test ist ein Programm, das Sie schreiben, debuggen und warten. Wenn sich Ihre API ändert, ändert sich die locustfile. Wenn ein neuer Ingenieur den Test ausführen muss, benötigt er eine passende Python-Umgebung. Und wenn Sie nicht bereits Python schreiben, wird die Sprache selbst zu einer Voraussetzung für die Beantwortung einer Frage, die nichts mit Python zu tun hat.

Wo das Code-First-Modell zur Reibung wird

Die Reibung zeigt sich an drei Stellen.

Erstens: Einrichtung. Bevor Sie überhaupt etwas messen, installieren Sie Python, erstellen eine virtuelle Umgebung, führen pip install locust aus und schreiben das Framework. Für einen schnellen "Kann dieser Endpunkt 50 Benutzer aufnehmen"-Check ist das mehr Infrastruktur als Nutzlast.

Zweitens: Duplizierung. Wahrscheinlich haben Sie diese Anfragen bereits irgendwo definiert. Vielleicht in Postman, vielleicht in einer .http-Datei, vielleicht in einem API-Client, den Ihr Team täglich verwendet. Die locustfile beschreibt Anfragen neu, die bereits existieren, einschließlich des Authentifizierungsflusses, der Header und der Anfragetexte. Jetzt pflegen Sie zwei Kopien desselben API-Wissens, und diese driften auseinander.

Drittens: Die Menschen, die die Antwort benötigen. Ein QA-Ingenieur, ein Produktmanager, der einen Launch erwartet, oder ein Frontend-Entwickler, der einfach nur wissen möchte, ob die API die Marketing-E-Mail überlebt, benötigen alle das Lasttestergebnis. Sie müssen nicht unbedingt Python lesen oder schreiben können, um es zu verdienen. Wenn der Test hinter einer locustfile eingeschlossen ist, ist die Antwort hinter einer bestimmten Fähigkeit eingeschlossen.

Wenn Ihre Lasttests wirklich Verzweigungslogik und benutzerdefinierte Protokoll-Clients benötigen, lohnt sich diese Reibung, und Locust ist das richtige Tool. Für den häufigen Fall von "Führen Sie meine echten API-Anfragen unter gleichzeitiger Last aus und zeigen Sie mir die Zahlen", lohnt es sich zu fragen, ob die Python-Schicht Ihnen überhaupt etwas bringt.

Der Apidog-Ansatz: Belasten Sie die Anfragen, die Sie bereits haben

Apidog geht Lasttests von der anderen Seite an. Sie schreiben kein Skript, das Anfragen beschreibt. Sie nehmen Anfragen, die Sie bereits erstellt haben, und führen sie unter Last aus. Die Einheit eines Lasttests ist ein Testszenario, das lediglich eine geordnete Reihe von API-Anfragen mit ihren Umgebungen, Variablen und bereits angehängten Zusicherungen ist. Wenn Sie Apidog verwendet haben, um einen Endpunkt zu testen oder zu debuggen, ist die Anfrage bereits vorhanden. Der Performance-Test verwendet sie wieder.

Hier ist der vollständige Ablauf.

1. Öffnen Sie das Testszenario, das Sie belasten möchten. Dies ist dasselbe Szenario, das Sie als normalen funktionalen Test ausführen würden, mit denselben Anfragen und denselben Umgebungsvariablen.
2. Wählen Sie aus, es als Performance-Test statt als einmaligen Durchlauf auszuführen.
3. Legen Sie die Anzahl der virtuellen Benutzer fest. Apidog unterstützt bis zu 100 virtuelle Benutzer, wobei jeder während des gesamten Tests parallel jede Anfrage im Szenario durchläuft.
4. Legen Sie die Testdauer fest. Dies ist die Zeit, wie lange die virtuellen Benutzer weiterlaufen.
5. Legen Sie eine Anlaufdauer fest, wenn Sie einen allmählichen Anstieg wünschen. Während der ersten X Minuten bringt Apidog Benutzer inkrementell online, anstatt alle auf einmal; setzen Sie sie auf 0, und jeder virtuelle Benutzer startet sofort.
6. Wenn Ihr Szenario datengesteuert ist, wählen Sie einen passenden Modus. "Zufällige Übereinstimmung" lässt jeden virtuellen Benutzer in jeder Schleife eine zufällige Zeile aus Ihren Testdaten ziehen; "Sequenzielle Übereinstimmung" durchläuft die Zeilen der Reihe nach.
7. Starten Sie den Test und beobachten Sie das Live-Panel.

Das Diagramm aktualisiert sich in Echtzeit. Für jede API im Szenario erhalten Sie die Gesamtzahl der Anfragen, den durchschnittlichen Durchsatz, die durchschnittliche Antwortzeit, die maximale und minimale Antwortzeit sowie Fehler. Fahren Sie mit der Maus über das Diagramm, um die Zahlen für einen bestimmten Zeitraum anzuzeigen. Eine Registerkarte "Fehler" schlüsselt die fehlgeschlagenen Anfragen auf, sodass Sie sehen können, welcher Endpunkt wann ins Stocken geriet. Wenn der Lauf beendet ist, behält die Registerkarte "Testberichte" den Verlauf bei, sodass Sie den heutigen Lauf mit dem der letzten Woche vergleichen können, nachdem Sie eine Änderung vorgenommen haben.

Der ganze Sinn ist, dass es keine locustfile zu schreiben und keine Python-Umgebung zu verwalten gibt. Die gleiche Anfrage, die Ihren Funktionstest bestanden hat, ist die Anfrage, die die Last erzeugt. Das ist der Unterschied zwischen der Beschreibung eines Lasttests und dessen Ausführung. Apidog ist eine All-in-One-API-Plattform, sodass Design, Debugging, Funktionstests und Lasttests eines Endpunkts alle gegen eine Definition dieses Endpunkts erfolgen.

Ein konkreter Vergleich

Nehmen wir an, Sie möchten bestätigen, dass ein Login-Endpunkt 100 gleichzeitige Benutzer zwei Minuten lang mit einer 30-sekündigen Anlaufzeit verarbeiten kann.

In Locust schreiben Sie eine Benutzerklasse mit einer Aufgabe, die Anmeldeinformationen sendet, behandeln das von der Antwort zurückgegebene Token, speichern es für nachfolgende Aufrufe, speichern die Datei, starten locust -f login_test.py, öffnen die Web-Benutzeroberfläche und geben 100 Benutzer, eine Spawn-Rate und eine Laufzeit ein. Wenn die Token-Behandlung falsch ist, debuggen Sie Python, bevor Sie Ihre API debuggen.

In Apidog öffnen Sie das Login-Testszenario, das Sie bereits erstellt haben, schalten es auf einen Performance-Test um, geben 100 für virtuelle Benutzer, 2 Minuten für die Dauer, 30 Sekunden für den Anlauf ein und starten es. Die Authentifizierung, die in Ihrem Funktionstest bereits funktionierte, funktioniert immer noch, da es dasselbe Szenario ist. Sie lesen die Antwortzeitkurve und die Fehlerrate, während sie auftreten.

Beide kommen zu derselben Art von Antwort. Der eine verlangt von Ihnen, zuerst ein Programm zu schreiben und zu warten. Der andere verwendet das wieder, was Sie bereits haben. Für komplexe, code-modellierte Benutzerpfade lohnt sich das Programm. Für die Frage "Ist mein Endpunkt unter Last schnell und stabil?" gewinnt die Wiederverwendung Zeit.

Ehrliche Grenzen auf beiden Seiten

Seien Sie sich der Kompromisse bewusst, denn die Wahl des falschen Tools verschwendet so oder so einen Tag.

Die Performance-Tests von Apidog sind auf 100 virtuelle Benutzer pro Durchlauf begrenzt, und die Last wird von Ihrem Rechner generiert, auf dem die App läuft. Wenn Sie Zehntausende von Benutzern simulieren oder Last aus mehreren geografischen Regionen gleichzeitig generieren müssen, geht dies über das hinaus, was der In-App-Performance-Test abdeckt, und ein verteiltes Setup wie Locust-Worker oder ein dedizierter Lastgenerierungs-Cluster ist die richtige Wahl. Apidog zeichnet auch fehlgeschlagene Anfragen statistisch auf, anstatt den vollständigen Anfrage- und Antworttext für jeden Fehler zu erfassen, sodass eine tiefgehende forensische Fehlersuche bei einem bestimmten fehlgeschlagenen Aufruf mitten in der Last nicht seine Stärke ist.

Der Kompromiss von Locust ist der, um den es in diesem ganzen Artikel geht. Die Leistungsfähigkeit kommt aus dem Code, und der Code ist ein fester Kostenfaktor. Sie pflegen eine locustfile pro Szenario, halten eine Python-Umgebung bereit und akzeptieren, dass jeder, der den Test ausführen möchte, Python lesen muss, um ihn zu verstehen. Bei sehr hohen virtuellen Benutzerzahlen und spezieller Protokolllogik erkaufen Sie sich mit diesen Kosten etwas Reales. Für die alltägliche API-Lastprüfung ist es Overhead.

Eine vernünftige Regel: Wenn Sie den Test als „Führe diese Anfragen mit dieser Parallelität für diese Dauer aus“ beschreiben können, greifen Sie zum In-App-Performance-Test. Wenn Sie bedingte Verzweigungen, gewichtete Aufgaben-Graphen, benutzerdefinierte Clients oder sechsstellige Benutzerzahlen benötigen, greifen Sie zu Code. Eine breitere Übersicht, wo jede Option passt, finden Sie in unserem Überblick über die besten Lasttest-Tools und dem Vergleich von API-spezifischen Lasttest-Tools.

Die zurückgegebenen Zahlen lesen

Ein Lasttest ist nur nützlich, wenn Sie wissen, was die Ausgabe bedeutet. Vier Metriken tragen das meiste Gewicht.

Durchsatz (RPS/TPS) ist die Anzahl der Anfragen oder Transaktionen pro Sekunde, die Ihre API tatsächlich bedient hat. Es ist die Obergrenze dessen, was Ihr System verarbeiten kann. Wenn der Durchsatz stagniert, während Sie weiterhin virtuelle Benutzer hinzufügen, haben Sie einen Sättigungspunkt gefunden.

Antwortzeit (Latenz) ist die Dauer, die jede Anfrage benötigte. Achten Sie auf den Durchschnitt, aber noch stärker auf das Maximum. Ein gesunder Durchschnitt mit einem unschönen Maximum bedeutet, dass einige Benutzer eine schlechte Erfahrung machen, auch wenn die meisten zufrieden sind. Tail-Latenz ist der Punkt, an dem echte Benutzer Schmerzen empfinden.

Fehlerrate ist der Anteil der Anfragen, die fehlgeschlagen sind. Ein sauberer Test bei geringer Last, der bei steigender Anzahl virtueller Benutzer beginnt, 500er oder Timeouts zu werfen, sagt Ihnen genau, wo das System zusammenbricht. Der Punkt, an dem Fehler beginnen, ist oft interessanter als die reine Durchsatzzahl.

Parallelität gibt an, wie viele virtuelle Benutzer aktiv sind. In Apidog ist dies die von Ihnen festgelegte Anzahl virtueller Benutzer, und der Anlauf steuert, wie schnell Sie diese erreichen. Das Anlaufen ist wichtig, da ein System, das 100 Benutzer, die schrittweise erreicht werden, verarbeiten kann, immer noch zusammenbrechen kann, wenn alle 100 gleichzeitig ankommen.

Wenn Sie eine tiefere Version davon wünschen, führt unser Leitfaden zum API-Leistungstest durch Metriken, Testtypen und wie man die Kurven liest, und der Artikel zu den Grundlagen des Leistungstests behandelt die breitere Disziplin.

Wie dies zu den Tools passt, mit denen Sie bereits vergleichen

Wenn Sie JMeter verwendet haben, ist das mentale Modell dem von Apidog ähnlich, da beide es Ihnen ermöglichen, einen Lasttest über eine Benutzeroberfläche statt über Code zu konfigurieren. JMeter tauscht dies gegen einen schwereren XML-basierten Testplan und eine steilere Lernkurve ein; unser JMeter Lasttest-Tutorial behandelt dies im Detail. Wenn Sie Lasttests mit dem Postman Collection Runner durchgeführt haben, haben Sie eine leichtere Version derselben Idee gesehen, die in Lasttests mit Postman behandelt wird, und Apidog bietet dedizierte Performance-Berichte zusätzlich zu Anfragen, die Sie auch für API-Tests ohne Postman verwenden können. Apidog liegt zwischen der Code-freien Einfachheit, die sich die Leute wünschen, und der Wiederverwendung von Anfragen, die Sie davon abhält, ein separates Framework zu pflegen.

Der gemeinsame Nenner all dessen ist, dass Ihr Lasttest das API-Wissen, das Sie bereits kodiert haben, wiederverwenden sollte und es nicht in einer neuen Sprache duplizieren darf. Locust dupliziert es in Python, weil Python seine Stärke ist. Apidog verwendet Ihre Szenarien wieder, weil Wiederverwendung seine Stärke ist.

Erste Schritte

Wenn Ihre Anfragen bereits in Apidog leben, können Sie in den nächsten fünf Minuten einen Performance-Test durchführen. Öffnen Sie ein Testszenario, schalten Sie es auf einen Performance-Test um, legen Sie die virtuellen Benutzer und die Dauer fest und starten Sie es. Wenn Sie von einer locustfile kommen und es leid sind, die Python-Schicht zu warten, erstellen Sie das Szenario einmal in der App neu, und Sie werden nie wieder Lasttest-Code für diesen Endpunkt schreiben.

Laden Sie Apidog herunter und richten Sie einen Performance-Test auf einen Endpunkt, den Sie bereits testen. Sie werden Durchsatz-, Latenz- und Fehlerratenkurven sehen, bevor Sie die entsprechende locustfile fertig geschrieben hätten. Locust bleibt die richtige Antwort für verteilte, code-modellierte Lasttests in massivem Maßstab. Für die Frage, die die meisten Entwickler tatsächlich stellen, führen Sie die Anfragen aus, die Sie bereits haben.

FAQ

Ist Apidog ein direkter Ersatz für Locust?

Nicht für jede Aufgabe. Für Lasttests von API-Anfragen mit bis zu 100 virtuellen Benutzern ohne Code zu schreiben, ersetzt Apidog den gesamten Locust-Workflow, da es Ihre bestehenden Testszenarien direkt ausführt. Für verteilte Last bei sehr hohen Benutzerzahlen oder benutzerdefinierte Nicht-HTTP-Protokolle, die in Code modelliert sind, ist Locust immer noch die bessere Wahl.

Muss ich Code schreiben, um in Apidog Lasttests durchzuführen?

Nein. Sie konfigurieren virtuelle Benutzer, Testdauer und Anlaufzeit in der Benutzeroberfläche, und der Test führt die Anfragen aus einem bereits erstellten Testszenario aus. Es gibt keine locustfile und keine Python-Umgebung einzurichten.

Wie viele virtuelle Benutzer kann Apidog simulieren?

Bis zu 100 virtuelle Benutzer in einem einzigen Performance-Test. Jeder durchläuft während der von Ihnen festgelegten Dauer parallel jede API im Szenario. Wenn Sie weitaus mehr oder Last aus mehreren Regionen benötigen, ist ein verteiltes code-basiertes Tool wie Locust die richtige Wahl.

Welche Metriken meldet der Apidog Performance-Test?

Für jede API im Szenario erhalten Sie die Gesamtzahl der Anfragen, den durchschnittlichen Durchsatz, die durchschnittliche Antwortzeit, die maximale und minimale Antwortzeit sowie Fehler, live in einem Diagramm aktualisiert. Eine Registerkarte "Fehler" schlüsselt fehlgeschlagene Anfragen auf, und die Registerkarte "Testberichte" speichert den Ausführungsverlauf, sodass Sie Vergleiche über Änderungen hinweg anstellen können.

Kann ich datengesteuerte Anfragen lasttesten?

Ja. Wenn Ihr Szenario durch Testdaten unterstützt wird, wählen Sie "Random Match", damit jeder virtuelle Benutzer in jeder Schleife eine zufällige Zeile zieht, oder "Sequential Match", um die Zeilen der Reihe nach zu durchlaufen.

Sollte ich Locust noch für irgendetwas verwenden?

Ja, wenn seine Stärken Ihren Anforderungen entsprechen: Code-definiertes Benutzerverhalten mit Verzweigungen und gewichteten Aufgaben, benutzerdefinierte Protokoll-Clients und verteilte Lastgenerierung, die weit über 100 virtuelle Benutzer hinausgeht. Verwenden Sie das richtige Tool für die Form des Tests.