eurofunk Kappacher GmbH

Etablierte Firma

Application Load Testing with k6

Daniel Knittl-Frank von eurofunk Kappacher spricht in seinem devjobs.at TechTalk darüber, wie die hohen Performance Anforderungen der im Unternehmen entwickelten Software erfüllt werden.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Application Load Testing with k6 zeigt Daniel Knittl-Frank (eurofunk Kappacher GmbH), wie sein Team die missionskritische Eurofunk operation center suite für Einsatz- und Kommandozentralen mit dem Open-Source-Tool k6 leistungs- und latenzseitig absichert. Er erläutert Testaufbau (Setup/Teardown/Default), Checks, Custom Metrics (Counter, Gauge, Rate, Trend), Thresholds, Gruppen/Tags sowie Workload-Modelle (open/closed) mit Szenarien und Rampen, zudem Protokollsupport für HTTP, gRPC und WebSockets (mit Cookie-Workaround). Abschließend zeigt er die Einbindung in GitLab CI und die Live-Auswertung via InfluxDB/Grafana, sodass Teams Regressionen früh erkennen und niedrige Latenzen sowie konsistente Antwortzeiten sicherstellen können.

Application Load Testing mit k6: Metriken, Thresholds und CI-Pipelines – Ein technischer Leitfaden aus „Application Load Testing with k6“ von Daniel Knittl-Frank (eurofunk Kappacher GmbH)

Kontext: Einsatzleitzentralen und warum Performance kein Luxus ist

Aus der Perspektive von DevJobs.at war „Application Load Testing with k6“ von Daniel Knittl-Frank ein konzentrierter Praxisblick in eine Welt, in der jede Sekunde zählt. Daniel, GNU/Linux-Enthusiast, FH-Lektor und Expert Developer bei eurofunk Kappacher GmbH, arbeitet an Software für Leitstellen – für Polizei, Feuerwehr, Rettung, Industrie und größere Flughäfen. Eurofunk liefert dafür Komplettlösungen: von der Hardware und Netzwerktechnik bis zur Software, die Disponenten im Ernstfall verwenden.

Im Zentrum steht die webbasierte Eurofunk Operation Center Suite (EOGS). Sie bündelt Incident-Management, Disposition, Kartenansichten mit Live-Positionsdaten und Status von Einheiten sowie direkte Sprachkommunikation via WebRTC im Browser. Zusätzlich integriert EOGS externe Ereignisquellen: Alarmanlagen, Rauch- und Brandmelder, CCTV/Videostreams und externe Webservices mit Zusatzinformationen für Einsätze.

Für diese missionskritische Software gelten harte Anforderungen: hohe Verfügbarkeit, niedrige Latenz, konsistente Antwortzeiten und stets aktuelle Informationen. Oder, wie Daniel es zugespitzt formuliert:

„In einer Notsituation zählt jede einzelne Sekunde.“

Genau deshalb testet das Team die Performance systematisch – mit k6.

k6 im Überblick: Open Source, JavaScript-Tests, Fokus auf Last

k6 ist ein Open-Source-Lasttest-Tool (AGPL), entwickelt in Go. Tests werden in JavaScript geschrieben. Laut Daniel ist der Funktionsumfang für neuere JavaScript-Features aktuell noch begrenzt (ES 5.1), Modulunterstützung ist jedoch vorhanden und erleichtert die Strukturierung von Tests. k6 wurde im Sommer von Grafana Labs übernommen. Für Teams, die Performance reproduzierbar und automatisiert prüfen wollen, trifft k6 einen klaren Sweet Spot: CLI-first, scriptbar, integrationsfreundlich.

Teststruktur: Setup, Default, Teardown, Summary

Ein k6-Test folgt einem wiederkehrenden Aufbau:

Setup: Daten anlegen oder Login durchführen.
Default-Funktion: Das Herzstück. Virtuelle Benutzer (VUs) rufen diese Funktion in einer Schleife auf und führen die eigentlichen Interaktionen aus – etwa HTTP- oder gRPC-Requests und WebSocket-Aktionen.
Teardown: Aufräumen, Daten löschen, Logout.
Summary: Am Ende erzeugt k6 eine Zusammenfassung. Sie lässt sich anpassen und aggregiert Checks, Metriken und Threshold-Ergebnisse.

k6 läuft auf der Kommandozeile. Wird ein Test gestartet, zeigt das Tool während der Ausführung Logs, Fehlschläge, verbleibende Laufzeit und weitere Live-Indikatoren. Die Kombination aus einfacher Teststruktur und unmittelbarer CLI-Rückmeldung macht es leicht, schnell Hypothesen zu prüfen und Skripte iterativ zu verfeinern.

Checks: Systematisch validieren, was wichtig ist

In Lasttests geht es nicht nur um Durchsatz, sondern auch um Korrektheit. k6 erlaubt es, beliebige Checks auf Objekte anzuwenden – typischerweise HTTP-Antworten. Beispiele:

Ist der HTTP-Status 200?
Stimmt der Content-Type (z. B. JSON)?
Enthält die Antwort ein Feld oder eine ID, die einem erwarteten Muster entspricht?

Diese Checks fließen automatisch in die Summary ein – mit grünen Häkchen für erfolgreiche und roten Markierungen für fehlgeschlagene Prüfungen. k6 zeigt zudem Prozent- und Absolutwerte der fehlerhaften Checks. Dadurch behalten Teams die fachliche Integrität ihrer Workflows auch unter Last im Blick.

Eigene Metriken: Counter, Gauge, Rate, Trend

Nicht alles, was fachlich zählt, ist „out of the box“ messbar. k6 bietet deshalb benutzerdefinierte Metriken in vier Typen:

Counter: Zähler, z. B. „Wie viele Frames/Kommandos empfangen?“
Gauge: Letzter/aktueller Wert, z. B. „Aktueller Statuscode“ in einem Szenario.
Rate: Verhältnis von Erfolgen/Fehlschlägen, z. B. „Fehlerquote eines spezifischen Ereignisses“.
Trend: Zeitreihen mit min/avg/median/Percentiles/max, z. B. „Antwortzeitverteilung eines Endpunkts“.

k6 rendert diese Metriken passend:

Counter mit Gesamtzahl und Test-Rate pro Sekunde.
Trend mit Durchschnitt, Minimum, Median, Perzentilen und Maximum.
Gauge als „last known value“.

Damit werden Analysen möglich, die über reine HTTP-Dauer hinausgehen und fachliche Ereignisse einbeziehen – ein wichtiger Punkt in komplexen, integrierten Anwendungen wie EOGS.

Thresholds: Explizite Qualitätsgrenzen, automatisches Test-Fail

Thresholds arbeiten auf globaler Ebene eines Tests – und sie sind das zentrale Instrument, um Performanceforderungen präzise auszudrücken. Beispiele, die Daniel nennt:

„Fail, wenn die durchschnittliche Antwortzeit > 100 ms.“
„Fail, wenn eine Rate unter 5 % fällt.“

Auch Thresholds erscheinen in der Summary mit klarer Erfolg-/Fehlermarkierung. Dieser Mechanismus eignet sich hervorragend, um Regressionen früh in Pipelines zu stoppen und Teams unmittelbar zu benachrichtigen.

Gruppieren und Taggen: Selektive Sicht auf Teilmengen

k6 unterstützt Gruppen und Tags, um Requests, Checks und Metriken zu kategorisieren oder Teilmengen zu bilden. So lassen sich z. B. Antwortzeiten eines spezifischen Endpunkts isolieren und mit eigenen Thresholds versehen. Tags können pro Check oder global für den gesamten Test vergeben werden – nützlich, wenn End-to-End-Skripte viele Pfade und Protokolle abdecken, man aber gezielt einen kritischen Abschnitt überwachen möchte.

Die Summary lesen: Automatische und benutzerdefinierte Kennzahlen

Daniel zeigte eine Test-Summary mit mehreren Metriken und Thresholds. Ein großer Teil kommt automatisch von k6:

Anzahl der ausgeführten Checks.
Empfangenes und gesendetes Datenvolumen.
Durchschnittsdauer pro Gruppe.
Antwortzeitverteilung (Anzahl Requests, Durchschnitt, Median usw.).

Zudem waren benutzerdefinierte Metriken sichtbar – etwa „SOC frames“ und „STUMP commands received“. Neben den Rohzahlen stellt k6 die abgeleitete Pro-Sekunde-Rate bereit. Genau diese Mischung aus allgemeinen und domänenspezifischen Größen macht die Summary für technische wie fachliche Stakeholder gleichermaßen aussagekräftig.

Workload-Modelle: Open vs. Closed und wie Szenarien in k6 gebaut werden

k6 trennt zwischen zwei Grundmodellen:

Open Workload: Die Ankunftsrate neuer Nutzer wird gesteuert. Beispiel: „100 Requests pro Sekunde“ – k6 injiziert so viele virtuelle Nutzer wie nötig, um diese Rate zu halten.
Closed Workload: Die Zahl gleichzeitiger Nutzer wird gesteuert. Beispiel: „16 VUs, die die Default-Funktion in einer Schleife ausführen.“

In k6 werden diese Varianten über Szenarien konfiguriert. Besonders wichtig: Last ist nicht nur statisch; Rampen sind entscheidend, um Systemverhalten während Anstieg und Abfall zu beobachten. Daniel beschreibt typische Rampen:

Start bei 0 Nutzern, Anstieg auf 50 in 1 Minute, 2 Minuten halten, dann Anstieg auf 100 in 1 Minute.
Analog mit Ankunftsraten: 0 RPS auf 50 RPS in 1 Minute, halten, dann weiter steigern – oder gezielt ramp-down.

Visualisiert zeigt sich:

Bei Rampen mit VUs entspricht die Nutzerkurve exakt der definierten Rampe.
Bei Ankunftsraten injiziert k6 automatisch VUs, um die Zielrate zu treffen.
In der Dauer-Ansicht spiegelt ein „grüner Hintergrundbereich“ die Anzahl an Requests und macht die Relation zur definierten Rate sichtbar.

Diese klare Trennung zwischen „Wie viele sind gleichzeitig unterwegs?“ und „Wie schnell kommen neue an?“ ist mehr als terminologische Genauigkeit – sie prägt Lastprofile, Fehlermuster und Stabilitätsaussagen.

Über HTTP hinaus: WebSockets und gRPC im Test

EOGS setzt WebSockets ein. k6 kann neben HTTP auch WebSockets und gRPC adressieren. Für WebSockets gilt:

Verbindung zu sicheren (WSS) und unverschlüsselten Endpunkten.
Senden und Empfangen von Nachrichten.
Messen von Dauern – z. B. Zeit bis zur Antwort.

Eine wichtige Beobachtung aus Daniels Praxis: Cookie-Support für WebSockets war „kind of broken“. Daran wird gearbeitet, ein Workaround ist verfügbar. Für Teams mit Authentifizierung/Cookies über WebSocket-Kanäle ist diese Randnotiz goldwert – sie spart Recherchezeit und hilft, Tests stabil aufzusetzen.

Kontinuierlich testen: GitLab CI, Docker, stündliche Läufe

Mission-critical heißt: Performance muss kontinuierlich überprüft werden. eurofunk betreibt die k6-Tests in einer GitLab-CI-Pipeline. Ein Docker-Image führt vordefinierte Tests beispielsweise stündlich aus. Konfigurierte Thresholds sorgen dafür, dass die Pipeline bei Regressionen fehlschlägt. Der Nutzen ist unmittelbar: automatisches E-Mail-Alerting bei Pipeline-Fehlschlag – und damit schnelles Reagieren, bevor sich Probleme in den Echtbetrieb durchschleichen.

Beobachtbarkeit: InfluxDB-Ausgabe und Live-Visualisierung in Grafana

k6 kann Ergebnisse in externe Outputs schreiben. Daniel nennt InfluxDB als Timeseries-Datenbank, in die k6 während des Testlaufs alle Metriken schreibt. Mit Grafana werden darauf Panels aufgebaut – so wird live sichtbar:

Wie viele Nutzer sind aktiv?
Wie entwickeln sich Antwortzeiten?
Treten unerwartete Fehler auf?
Verlangsamt sich das System über die Testdauer?
Besteht eine erkennbare Korrelation zwischen Nutzerzahl und Latenz?

Diese Live-Sicht ist besonders hilfreich für Rampen und für Fehlersuche unter Produktionsähnlichen Lastprofilen. Zusammen mit den k6-Thresholds entsteht so ein Kreislauf aus schneller Erkennung und gezielter Analyse – beides unverzichtbar für robuste Systeme.

Praktischer Fahrplan für Engineering-Teams

Aus dem Talk lassen sich für Teams, die k6 evaluieren oder vertiefen wollen, klare Schritte ableiten. Alle Punkte basieren auf den im Vortrag besprochenen Möglichkeiten:

Anforderungen klären

Latenzziele und Konsistenzanforderungen definieren (z. B. Average, Median, Perzentile, Max).
Kritische Benutzerpfade und Protokolle identifizieren (HTTP, WebSockets, ggf. gRPC).
Fachliche Integritätschecks festlegen: Welche Felder/Muster müssen in Antworten vorhanden sein?

Teststruktur aufsetzen

Setup/Teardown logisch gestalten (z. B. Login/Logout, Datenpräparation und -bereinigung).
Default-Funktion als realitätsnahe Sequenz modellieren, die VUs in einer Schleife ausführen.

Checks systematisch integrieren

Statuscodes, Content-Types, Antwortinhalte prüfen.
Checks im Summary-Output beobachten und Fehlerquoten bewerten.

Eigene Metriken definieren

Counter/Rate für Ereignisse, die k6 nicht automatisch erfasst.
Trendmetrik für kritische Zeitreihen (z. B. Antwortzeit je Endpoint).
Gauge für „letzter Zustand“ in spezifischen Szenarien.

Thresholds als Qualitätsgrenzen setzen

Globale Schwellenwerte, die bei Verstößen den Test fehlschlagen lassen.
In Kombination mit Tags/Groups auch für Teilmengen (z. B. pro Endpoint).

Workload-Modelle passend wählen

Closed Model: „Wie viele gleichzeitig?“ – gut für Concurrency-Tests.
Open Model: „Wie schnell kommen neue an?“ – gut für RPS-getriebene Lastprofile.
Rampen planen (Up/Down), um Stabilität über Übergänge zu validieren.

Protokolle über HTTP hinaus berücksichtigen

WebSockets nachbilden: Senden/Empfangen, Dauer messen.
Cookie-Handling bei WebSockets beachten; bekannten Workaround einplanen.
gRPC-Testoptionen evaluieren, wenn relevant.

CI-Pipeline etablieren

Dockerisierte k6-Jobs in GitLab CI (z. B. stündlich oder täglich).
Thresholds als Gate – Fail bei Regressionen, automatische E-Mail-Benachrichtigung nutzen.

Ergebnisse live observieren

k6-Output nach InfluxDB routen.
Grafana-Panels für Nutzerzahl, Latenzen, Fehler und Trends erstellen.
Relation zwischen Last und Latenz in Echtzeit prüfen.

Iterativ verbessern

Auffälligkeiten aus Grafana/Influx und der k6-Summary in Hypothesen übersetzen.
Skripte, Checks, Metriken und Thresholds schrittweise verfeinern.

Lernpunkte aus dem Talk

Performance ist Teil der Funktionalität – besonders in Leitstellenumgebungen. Das spiegelt sich in den strengen Zielen: hohe Verfügbarkeit, niedrige Latenz, konsistente Antwortzeiten.
k6 bietet eine klare, skriptbare Struktur mit Setup/Default/Teardown und einer aussagekräftigen Summary. Checks und eigene Metriken heben Lasttests von bloßem „Durchsatzmessen“ auf ein Qualitätsniveau, das Fachlogik einschließt.
Thresholds sind der Motor für Automatisierung. Sie machen Performancevorgaben maschinenlesbar und CI-fähig – und sorgen im Fehlerfall für unmittelbare Sichtbarkeit.
Open vs. Closed Workload ist mehr als eine akademische Unterscheidung. Es beeinflusst, wie Systeme Last wahrnehmen und wo Engpässe auftreten.
WebSockets gehören zum Repertoire. Wichtiger Praxis-Tipp: Cookie-Handling im Blick behalten und Workaround nutzen.
Mit InfluxDB und Grafana entsteht ein Live-Fenster in laufende Tests. Das beschleunigt Diagnose und schafft Vertrauen in die gemessenen Effekte – ob in Rampen oder unter stabiler Last.

Fazit: Struktur, Metriken und Automatisierung – k6 in der Praxis

Daniel Knittl-Frank zeigt in „Application Load Testing with k6“, wie Performancearbeit in einer missionskritischen Umgebung konkret aussieht: strukturiert über Setup/Default/Teardown, präzise über Checks, Metriken, Gruppen/Tags und Thresholds, praxisnah über Open/Closed-Modelle und Rampen – und kontinuierlich über GitLab-CI mit Docker sowie Live-Analysen in InfluxDB/Grafana.

Mit diesem Setup lässt sich – so der Vortrag – sicherstellen, dass Anwendungen „smoothly“ laufen, niedrige Latenzen halten und konsistente Antwortzeiten liefern.

Für Engineering-Teams, die Lasttests als festen Bestandteil ihres Qualitätsprozesses verankern wollen, liefert die Session eine klare Roadmap. Keine exotischen Abkürzungen, sondern robuste Bausteine: reproduzierbare Szenarien, domänenspezifische Metriken, harte Thresholds, kontinuierliche Läufe und aussagekräftige Visualisierung. Genau das braucht es, wenn im Ernstfall jede Sekunde zählt.