gRPC-Lasttest: Tools, Einrichtung und Kennzahlen

Q: Kann man gRPC-Streaming-Aufrufe lasttesten?

Ja, mit k6 und ghz. Das gRPC-Modul von k6 hat eine Klasse `Stream` mit `write`, `end` und Event-Handlern, und ghz hat Optionen für Streaming-Intervalle und -Dauern. Messen Sie gesendete und empfangene Nachrichten ebenso wie die Latenz der Aufrufe.

16. Oktober 2026 6 Min. Lesezeit

Für einen gRPC-Lasttest brauchen Sie ein Tool, das HTTP/2 und Protocol Buffers spricht: k6 und ghz können das von Haus aus, JMeter braucht ein Plugin, Gatlings gRPC-Unterstützung ist in der kostenlosen Edition begrenzt, und bei Locust müssen Sie selbst einen gRPC-Client einbinden. Werten Sie die Ergebnisse nach gRPC-Status aus, nicht nach HTTP-Status, denn fehlgeschlagene Aufrufe kommen trotzdem als HTTP 200 an, und prüfen Sie, ob die Last jedes Backend erreicht.

Für diesen Artikel wurde kein gRPC-Test ausgeführt. Die Fakten zu den Tools stammen aus der Dokumentation und den Repositories der jeweiligen Projekte, geprüft am 16. Oktober 2026; die Fakten zu LoadFocus stammen aus dessen Code.

Tool	gRPC-Unterstützung	Liest die API aus	Ratensteuerung
k6	Eingebaut (`k6/net/grpc`), unäre Aufrufe und Streams	`.proto`-Dateien oder Server Reflection	Arrival-Rate-Executors
ghz	Eigenes gRPC-Kommandozeilentool	`.proto`, Protoset oder Server Reflection	`--rps` und Lastpläne
JMeter	Plugin eines Drittanbieters (jmeter-grpc-request)	Einem Ordner mit `.proto`-Dateien	Thread Groups und Timer
Gatling	Eigene gRPC-Komponente; kostenlose Edition auf 5 Benutzer, 5 Minuten begrenzt	Mit protoc aus `.proto` generiertem Code	Injektionsprofile
Locust	Kein eingebauter Client; einen einbinden und Aufrufe melden	Ihrem Python-gRPC-Client	Wartezeiten, `constant_throughput`

Warum braucht gRPC einen anderen Lasttest als REST?

gRPC läuft über HTTP/2, sendet binäre Protocol Buffers statt JSON, legt das Ergebnis eines Aufrufs in einen Trailer statt in den HTTP-Status und bündelt viele Aufrufe auf einer Verbindung. Jeder dieser Punkte ändert, wie Sie den Test skripten oder seine Ergebnisse lesen.

Der Beitrag zum gRPC-Load-Balancing nennt die HTTP/2-Eigenschaften, auf die es hier ankommt: ein binäres Protokoll, viele Anfragen gemultiplext auf einer Verbindung und Header-Kompression, darüber stark typisierte Protobuf-Nachrichten (geprüft am 16. Oktober 2026). Ein Tool, das nur JSON über HTTP/1.1 sendet, kann keine gRPC-Methode aufrufen, prüfen Sie also zuerst die Protokollunterstützung.

Welches Tool sollten Sie verwenden?

Nehmen Sie k6, wenn Sie Szenarien, Checks und Schwellenwerte als Code wollen; nehmen Sie ghz für einen schnellen Benchmark einer Methode von der Kommandozeile. Greifen Sie zu JMeter, Gatling oder Locust, wenn Ihr Team alles andere bereits damit testet.

k6. Das Modul k6/net/grpc lädt Protobuf-Definitionen, baut Verbindungen auf, macht unäre Aufrufe mit invoke und öffnet Streams. Es meldet grpc_req_duration und die Zahl der Stream-Nachrichten in seinen Metriken.
ghz. Ein reines gRPC-Benchmark-Tool für die Kommandozeile. Zu seinen Optionen gehören --rps, --concurrency, --total und --duration, und wenn Sie weder --proto noch --protoset angeben, versucht es Server Reflection. Das neueste Release ist v0.121.0 (geprüft am 16. Oktober 2026).
JMeter. Der JMeter-Kern hat keinen gRPC-Sampler; das Plugin jmeter-grpc-request fügt einen hinzu, der einen Ordner mit .proto-Dateien liest, ohne Codegenerierung (neuester Tag v1.2.6, geprüft am 16. Oktober 2026).
Gatling. Die Gatling-README stellt gRPC, MQTT und GraphQL unter die Gatling Enterprise Component License, in der Community Edition begrenzt auf 5 gleichzeitige Benutzer und 5 Minuten Testdauer (geprüft am 16. Oktober 2026). Die Anleitung zur gRPC-Einrichtung generiert Code aus Ihren .proto-Dateien mit protoc.
Locust. Die Dokumentation zum Testen anderer Systeme enthält ein gRPC-Beispiel: Sie umhüllen einen gRPC-Client, damit jeder Aufruf an Locust gemeldet wird, und constant_throughput taktet eine Aufgabe auf höchstens eine feste Zahl von Läufen pro Sekunde.

Nehmen Sie ghz statt k6, wenn Sie nur wissen müssen, wie sich eine Methode bei einer bestimmten Rate verhält, und kein Skript schreiben wollen. Nehmen Sie stattdessen Locust, wenn Ihr Team in Python schreibt und der Test Logik braucht, die dort einfacher ist.

Wie schreiben Sie einen gRPC-Lasttest in k6?

Laden Sie die .proto-Datei im Init-Code, dann bauen Sie in jeder Iteration die Verbindung auf, rufen die Methode auf und prüfen den gRPC-Status. Der Aufbau folgt dem Beispiel aus der k6-Dokumentation.

import grpc from 'k6/net/grpc';
import { check } from 'k6';

const client = new grpc.Client();
client.load(['protos'], 'hello.proto');

export const options = { vus: 20, duration: '1m' };

export default () => {
  client.connect('grpc.example.com:443');
  const res = client.invoke('hello.Greeter/SayHello', {
    name: 'load test',
  });
  check(res, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
};

Die Seite zu invoke nutzt dieselbe Abfolge aus Laden, Verbinden, Aufrufen, Prüfen und Schließen. connect verwendet TLS, außer Sie übergeben plaintext: true, und mit reflect: true fragt es den Server nach seiner API, statt eine .proto-Datei zu lesen (Verbindungsparameter). Um eine Anfragerate statt einer Benutzerzahl zu halten, führen Sie die Funktion in einem Arrival-Rate-Szenario aus.

Wie machen Sie einen schnellen Benchmark mit ghz?

Geben Sie ghz die Methode, einen Anfrage-Body und eine Rate oder Parallelität, und es gibt ein Latenz-Histogramm, Perzentile und eine Zählung pro Statuscode aus. Das passt für einen ersten Blick auf eine Methode.

ghz --insecure --proto ./hello.proto \
  --call hello.Greeter.SayHello \
  -d '{"name":"load test"}' \
  --rps 200 -c 50 -z 1m \
  localhost:50051

--rps setzt die angestrebte Anfragerate, verteilt auf die Worker, -c bestimmt, wie viele Worker es gibt, und -z die Dauer. Lassen Sie --proto weg, damit ghz Server Reflection nutzt, sofern der Server sie aktiviert hat. Die Ausgabeseite von ghz zeigt einen Beispielbericht.

Was sollten Sie in einem gRPC-Lasttest messen?

Messen Sie Latenz-Perzentile der Aufrufe, den Durchsatz und die Zahl jedes gRPC-Statuscodes. Eine Erfolgsquote auf HTTP-Ebene kann 100 % zeigen, während Aufrufe fehlschlagen, weil das Ergebnis im Trailer grpc-status steht.

Die gRPC-Spezifikation für HTTP/2 setzt den HTTP-Status auf :status 200 und überträgt das Ergebnis des Aufrufs in Trailern als grpc-status und grpc-message. Die Liste der Statuscodes enthält die Codes, die unter Last am meisten zählen:

DEADLINE_EXCEEDED (4): die Deadline lief ab, bevor der Aufruf fertig war.
RESOURCE_EXHAUSTED (8): ein Kontingent oder eine Ressource war erschöpft.
INTERNAL (13): eine interne Invariante ist verletzt, ein Code für schwere Fehler.
UNAVAILABLE (14): meist vorübergehend; ein erneuter Versuch mit Backoff kann helfen, ist bei nicht idempotenten Aufrufen aber nicht immer sicher.

Zählen Sie jeden Code pro Laststufe. Deadline-Fehler können steigen, während die erfolgreichen Aufrufe noch schnell aussehen, weil die langsamen an der Deadline abgebrochen werden, statt als langsam erfasst zu werden. Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests zeigt, wie Sie aus diesen Zahlen Schwellenwerte machen.

Warum landet die ganze Last auf einem Server?

Weil gRPC viele Aufrufe auf einer langlebigen Verbindung bündelt, schickt ein Load Balancer, der pro Verbindung arbeitet, jeden Aufruf darauf an dasselbe Backend. Ein Lastgenerator mit wenigen Verbindungen kann dann einen Server auslasten, während die anderen untätig sind.

Der Beitrag zum gRPC-Load-Balancing erklärt den Mechanismus. Ein Balancer auf Transportebene (L3/L4) terminiert die TCP-Verbindung und öffnet eine weitere zu einem gewählten Backend und kopiert die HTTP/2- und gRPC-Frames zwischen beiden; ein Balancer auf Anwendungsebene (L7) parst HTTP/2 und kann die Streams einer Client-Verbindung auf mehrere Backends verteilen. Laufen Ihre Produktions-Clients über einen L7-Balancer oder balancieren clientseitig, testen Sie über denselben Weg und prüfen Sie während des Laufs CPU und Anfragezahlen pro Backend.

Können Sie gRPC-Lasttests auf LoadFocus ausführen?

Nicht so, dass seine Berichte sie zeigen würden. LoadFocus führt das unveränderte k6-Release v0.57.0 aus, das das gRPC-Modul enthält, aber sein k6-Agent leitet nur HTTP-Anfragewerte an die Ergebnisse weiter, sodass gRPC-Aufrufe Last erzeugen würden, ohne in seinen Diagrammen oder Fehlerzahlen aufzutauchen.

Dazu kommen zwei weitere Grenzen. Der k6-Upload akzeptiert .js-, .ts-, .csv-, .txt-, .json-, .env- und .properties-Dateien, keine .proto-Dateien, ein Skript müsste sich also mit reflect: true verbinden. Und der Weg über JMeter ist verschlossen: Die JMeter-Agenten von LoadFocus bringen JMeter 5.6.2 mit vorinstallierten Plugins mit, unter denen kein gRPC-Sampler ist, und der JMeter-Upload akzeptiert keine Plugin-JAR-Dateien. Für gRPC führen Sie k6 oder ghz auf eigenen Rechnern aus und nutzen k6-Skripte auf LoadFocus für die HTTP-Seite desselben Systems, wo es Last aus 25 Regionen erzeugt.

FAQ

Kann man gRPC-Streaming-Aufrufe lasttesten? Ja, mit k6 und ghz. Das gRPC-Modul von k6 hat eine Klasse Stream mit write, end und Event-Handlern, und ghz hat Optionen für Streaming-Intervalle und -Dauern. Messen Sie gesendete und empfangene Nachrichten ebenso wie die Latenz der Aufrufe.

Braucht man die .proto-Datei, um einen gRPC-Dienst zu lasttesten? Nicht, wenn der Server Reflection aktiviert hat. k6 kann sich mit reflect: true verbinden, und ghz greift auf Reflection zurück, wenn Sie weder --proto noch --protoset angeben. Ohne Reflection brauchen Sie die .proto-Datei oder ein kompiliertes Protoset.

Warum erscheinen meine gRPC-Fehler nicht als fehlgeschlagene Anfragen? Weil der HTTP-Status eines gRPC-Aufrufs auch bei einem Fehler 200 ist. Das Ergebnis steht im Trailer grpc-status, prüfen Sie also diesen Wert in Ihrem Skript und zählen Sie jeden Code einzeln.

Weiterlesen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.

LoadFocus team

Geschrieben vom LoadFocus-Team, den Leuten hinter einem Cloud-Lasttest-Dienst.