WebSocket-Lasttest-Tools: sechs Optionen im Vergleich

Q: Sollte ich k6/ws oder k6/websockets verwenden?

Nehmen Sie für neue Tests `k6/websockets`, wie die Dokumentation von k6 empfiehlt. Das ältere Modul `k6/ws` ist für bestehende Skripte weiter dokumentiert.

9. Oktober 2026 6 Min. Lesezeit

WebSocket-Lasttest-Tools mit eingebauter Unterstützung sind k6, Artillery, Gatling und Tsung, während JMeter das Plugin WebSocket Samplers braucht und Locust eigenen Client-Code oder seinen experimentellen Socket.IO-User. Wählen Sie nach der Sprache, in der Ihr Team schreibt, und danach, wie genau Sie die Nachrichten prüfen müssen, die der Server zurückschickt.

Für diesen Artikel haben wir die Tools nicht gegen einen WebSocket-Server laufen lassen. Die Fakten stammen aus der Dokumentation und den Repositories der Projekte, geprüft am 9. Oktober 2026, und die Hinweise „Wählen Sie stattdessen“ sind unsere Einschätzung.

Tool	WebSocket-Unterstützung	Tests geschrieben in	Prüfen, was der Server sendet
k6	Eingebaut: `k6/websockets`, älter `k6/ws`	JavaScript	Event-Handler in Ihrem Skript
Artillery	Eingebaute Engines `ws` und `socketio`	YAML, dazu JavaScript-Funktionen	Socket.IO-Antworten und Acknowledgements
Gatling	Teil des HTTP-SDK	Java, Kotlin, Scala, JavaScript	Checks, die auf eine erwartete Nachricht warten
Apache JMeter	Plugin WebSocket Samplers	In der GUI gebaute Testpläne	Request-Response- und Lese-Sampler
Locust	Eigener Client oder der experimentelle `SocketIOUser`	Python	Was Ihr Code meldet
Tsung	Eingebauter Sitzungstyp `ts_websocket`	XML	`ack` wartet auf eine Serverantwort

Was unterscheidet WebSocket-Last von HTTP-Last?

Ein WebSocket-Benutzer öffnet eine Verbindung und hält sie die ganze Sitzung über, und der Server kann jederzeit Nachrichten senden. Ein Test hat deshalb zwei Stellschrauben, offene Verbindungen und Nachrichten pro Sekunde, und jede belastet den Server auf eigene Weise.

Der WebSocket-Leitfaden von k6 beschreibt Vollduplex-Verkehr über eine einzige TCP-Verbindung und erklärt, dass ein virtueller Benutzer dabei eine Event-Loop ausführt, solange der Socket offen ist, und die Hauptfunktion nicht mehr in Schleife durchläuft. Die WebSocket-Referenz von Gatling ergänzt, dass der Verkehr in beide Richtungen fließt, sodass das HTTP-Modell aus Anfrage und Antwort nicht mehr passt.

Planen Sie drei Arten von Tests. Viele untätige Verbindungen zeigen, wie viele Sockets Ihre Server halten können. Eine kleinere Gruppe gesprächiger Clients prüft die Nachrichtenverarbeitung. Ein Broadcast, bei dem eine Nachricht an alle Abonnenten geht, prüft den Push-Pfad.

Was sollten Sie in einem WebSocket-Lasttest messen?

Messen Sie Verbindungsaufbauzeit, Nachrichtenlatenz und abgebrochene Verbindungen, dazu, wie viele Verbindungen offen bleiben. Diese Werte zeigen, was Nutzer einer Echtzeit-App spüren.

Zu den eingebauten Metriken von k6 gehören ws_connecting, ws_ping, ws_session_duration, ws_sessions und Nachrichtenzähler. Keine davon misst eine Anwendungsnachricht, für die Zeit zwischen der Nachricht eines Clients und der Antwort des Servers brauchen Sie also eine eigene Trend-Metrik. Die ws-Engine von Artillery meldet Nachrichtenzähler und -raten, und ihre Socket.IO-Engine ergänzt socketio.response_time, die Zeit vom Senden einer Nachricht bis zur Antwort.

Für abgebrochene Verbindungen zählen Sie Close- und Error-Events, die Ihr Skript nicht selbst ausgelöst hat, und vergleichen die gestarteten Sitzungen mit denen, die am Ende jeder Stufe noch offen sind.

Wann ist k6 das richtige WebSocket-Tool?

Wenn Ihr Team JavaScript schreibt und jeder virtuelle Benutzer mehrere Sockets gleichzeitig halten soll. k6 bringt WebSocket-Unterstützung von Haus aus mit, ohne Erweiterung.

Das Modul k6/websockets folgt der WebSocket-API des Browsers und nutzt eine globale Event-Loop, mit der ein virtueller Benutzer mehrere Verbindungen offen halten kann. Das ältere Modul k6/ws ist weiter dokumentiert, k6 empfiehlt für neue Tests aber k6/websockets, und k6/experimental/websockets ist veraltet.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Thresholds funktionieren auch mit eigenen Metriken, ein verfehltes Latenzziel liefert der CI also einen Exit-Code ungleich null. Wählen Sie stattdessen Artillery, wenn Ihr Server Socket.IO spricht und Sie Emits und Acknowledgements ohne eigenen Client-Code prüfen wollen. Die weiteren Unterschiede behandelt unser Vergleich k6 vs Artillery.

Wann passt Artillery?

Wenn Sie kurze YAML-Szenarien wollen oder Ihr Server Socket.IO nutzt. Beide Engines sind in Artillery selbst enthalten.

Ein Szenario auf der WebSocket-Engine besteht aus fünf Aktionen: connect, send, think, loop und function. Die Socket.IO-Engine geht weiter: Ein emit kann die erwartete Antwort angeben, ein Acknowledgement per JSONPath-Abgleich prüfen und sich ein Szenario mit HTTP-Anfragen teilen, was zu Apps passt, die sich per HTTP anmelden, bevor sie einen Socket öffnen.

Wählen Sie stattdessen k6 oder Gatling, wenn ein Test prüfen muss, was ein reiner WebSocket-Server zurückschickt, denn die Dokumentation der ws-Engine beschreibt keinen Schritt, der auf eine Antwort wartet oder sie abgleicht.

Für wen ist Gatling bei WebSockets gedacht?

Für Teams auf der JVM oder mit dem JavaScript-SDK von Gatling, die Prüfungen von Nachrichten direkt ins Szenario schreiben wollen. WebSocket-Unterstützung ist Teil des HTTP-SDK von Gatling, HTTP- und WebSocket-Schritte teilen sich also eine Simulation.

Die Referenz behandelt connect, sendText, sendBytes und close sowie Checks, die blockieren, bis die erwartete Nachricht eintrifft oder ein Timeout abläuft. Über Protokolleinstellungen lassen sich vom Server geschlossene Sockets neu verbinden, ausgewählte Textnachrichten wie ein Ping automatisch beantworten und Nachrichten puffern, auf die kein Check gepasst hat. Laut Repository gehört WebSocket ohne Einschränkungen zur Community-Edition unter Apache 2.0.

Wählen Sie stattdessen k6, wenn Sie auf gepushte Nachrichten lieber in Event-Handlern reagieren als mit blockierenden Checks.

Kann JMeter WebSockets lasttesten?

Ja, mit einem Plugin. JMeter selbst hat keinen WebSocket-Sampler, die übliche Erweiterung ist WebSocket Samplers von Peter Doornbosch.

Die Komponentenreferenz von JMeter erwähnt WebSocket überhaupt nicht. Das Repository des Plugins beschreibt sechs Sampler: Verbindung öffnen, Request-Response, Ping-Pong, einzelnes Lesen, einzelnes Schreiben und Schließen. Sie laufen im Thread der Thread-Gruppe, unterstützen wss und Binärframes und können Frames herausfiltern, die für einen Test keine Rolle spielen. Installiert wird es über den Plugins Manager oder als JAR in lib/ext; Version 1.3.2 wurde im Januar 2026 getaggt (geprüft am 9. Oktober 2026).

Wählen Sie ein anderes Tool, wenn Sie kein Drittanbieter-Plugin auf jedem Lastgenerator pflegen möchten.

Was ist mit Locust und Tsung?

Locust erreicht reine WebSockets nur über Client-Code, den Sie selbst ergänzen, und Tsung unterstützt sie in seiner XML-Konfiguration, veröffentlicht aber selten neue Versionen. Beides funktioniert, mit mehr Aufwand.

Laut der Dokumentation von Locust unterstützt das Tool von Haus aus nur HTTP und HTTPS; andere Protokolle kommen hinzu, indem Sie eine Client-Bibliothek kapseln und nach jedem Aufruf das Event request auslösen. Die Bibliothek muss sich von gevent patchen lassen, sonst blockiert sie den ganzen Prozess. Für Socket.IO gibt es einen experimentellen SocketIOUser. Wählen Sie Locust, wenn Ihr Team Python schreibt und diesen Client-Code gern selbst pflegt.

Tsung ist ein Erlang-Projekt, das sich als verteiltes Lasttest-Tool für mehrere Protokolle beschreibt. Seine Sitzungsdokumentation definiert für WebSocket die Anfragen connect, message und close, mit einem Attribut ack, um auf eine Antwort zu warten. Die letzte getaggte Version, 1.8.0, stammt vom März 2023.

Wo passt ein gehosteter Runner wie LoadFocus hinein?

Viele offene Sockets von eigenen Rechnern zu halten, macht Arbeit, und ein gehosteter Runner übernimmt die Lasterzeugung. Am besten passt das, wenn Ihre Tests schon k6-Skripte sind.

LoadFocus, der Herausgeber dieser Website, führt k6-Skripte aus 25 Cloud-Regionen aus, und seine k6-Seite nennt WebSocket-Verbindungen unter den unterstützten k6-Funktionen. Außerdem gibt es eine Vorlage für WebSocket-Tests mit Ramp-up und Ramp-down (auf Englisch). Ob LoadFocus JMeter-Plugins wie WebSocket Samplers ausführt, haben wir nicht geprüft, dazu machen wir also keine Aussage.

Wie wählt man zwischen ihnen?

Gehen Sie von der Sprache Ihres Teams aus und fragen Sie dann, ob Sie reine WebSockets oder Socket.IO testen und wie streng Sie gepushte Nachrichten prüfen müssen. Danach bleiben meist ein oder zwei Kandidaten.

Schreiben Sie in beiden denselben kurzen Test mit Verbinden, Senden und Empfangen, und vergleichen Sie Verbindungsaufbauzeit und Nachrichtenlatenz bei geringer Last. Unsere Anleitung Lasttest durchführen führt durch die Schritte, und der Überblick Open-Source-Lasttest-Tools vergleicht diese Projekte über WebSockets hinaus.

FAQ

Mit welchem WebSocket-Lasttest-Tool sollte ich anfangen? Wenn Ihr Team JavaScript schreibt, beginnen Sie mit k6, das WebSocket-Unterstützung eingebaut hat. Für Socket.IO-Apps braucht die Engine von Artillery am wenigsten Code, und JVM-Teams fühlen sich in Gatling zu Hause.

Kann JMeter WebSockets ohne Plugin testen? Die Komponentenreferenz nennt keinen WebSocket-Sampler, der praktische Weg ist also das Plugin WebSocket Samplers, installiert über den Plugins Manager oder als JAR in lib/ext.

Sollte ich k6/ws oder k6/websockets verwenden? Nehmen Sie für neue Tests k6/websockets, wie die Dokumentation von k6 empfiehlt. Das ältere Modul k6/ws ist für bestehende Skripte weiter dokumentiert.

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.