Site icon bintorosoft.com

Network-Performance-Tests: iperf vs. realer Workload

Red Snapper

Network-Performance-Tests: iperf vs. realer Workload ist ein Klassiker in Infrastruktur- und Kubernetes-Teams, weil beide Seiten im Alltag berechtigte Argumente haben – und trotzdem regelmäßig aneinander vorbeireden. Auf der einen Seite liefert iperf (bzw. iperf3) schnell Zahlen: Durchsatz, Jitter, Packet Loss, Parallelströme. Auf der anderen Seite kommt dann der Einwand: „Unsere Anwendung erreicht davon in Produktion nur einen Bruchteil“ oder „Die Latenz ist gut, aber die Timeouts bleiben“. Das Problem ist selten, dass iperf „falsch“ misst. Das Problem ist, dass iperf eine sehr spezifische Art von Traffic erzeugt, während reale Workloads ganz andere Muster haben: viele kurze Verbindungen statt einer langen, TLS und Auth statt Klartext, Request/Response statt reiner Stream, Backpressure, Connection Pools, Retries, Load Balancer, Sidecars, NAT, Conntrack, DNS, MTU und nicht zuletzt CPU- und Speicherlimitierung in Containern. Wer Network-Performance-Tests richtig einsetzt, trennt daher konsequent zwei Ziele: (1) die Rohfähigkeit des Pfads (Kapazität und Stabilität) und (2) die Anwendungsrealität (Effizienz der Protokolle, Libraries und Plattformkomponenten). Dieser Artikel zeigt, was iperf gut kann, wo es systematisch irreführend wird und wie Sie Tests so designen, dass die Ergebnisse belastbar auf den realen Workload übertragbar sind.

Was iperf tatsächlich misst und warum das so attraktiv ist

iperf ist beliebt, weil es schnell und reproduzierbar eine Baseline liefert. Sie starten Server und Client, wählen TCP oder UDP, definieren Dauer, Parallelität und optional Paketgröße. Das Ergebnis ist eine handliche Zahl: „X Gbit/s“ oder „Y Mbit/s“, plus Zusatzinformationen wie Retransmits (TCP) oder Jitter/Verlust (UDP). Für Infrastrukturteams ist das wertvoll, weil es unabhängig von einer konkreten Anwendung zeigt, ob ein Pfad grundsätzlich leisten kann, was er verspricht.

Als Referenz für Parameter und Output ist die offizielle iperf3-Dokumentation hilfreich: iperf3 Dokumentation und Optionen.

Warum iperf-Ergebnisse oft nicht zur Anwendung passen

Reale Anwendungen sind selten „ein großer Datenstrom von A nach B“. Typisch sind Mischformen: kleine Requests, variable Payloads, burstiger Traffic, TLS, Proxies, Rate-Limits, Backpressure und Workload-spezifische Latenzanforderungen. iperf bildet das nur teilweise ab. Das führt zu drei typischen Fehlinterpretationen:

Ein praktischer Merksatz: iperf zeigt, was das Netzwerk unter Laborbedingungen kann. Realer Workload zeigt, was Ihr gesamter Stack daraus macht.

TCP vs. UDP: iperf-Tests sind nicht automatisch „realistisch“

Viele Teams nutzen iperf standardmäßig mit TCP. Das ist nachvollziehbar, weil die meisten Anwendungen TCP-basierte Protokolle nutzen (HTTP/1.1, HTTP/2, gRPC, Datenbanken). Trotzdem kann TCP in iperf erheblich von realem TCP-Verhalten abweichen:

UDP-Tests sind wiederum hilfreich, um Verlust und Jitter sichtbar zu machen, aber sie sind für TCP-Anwendungen nur indirekt aussagekräftig. Ein UDP-Test kann „ok“ aussehen, während TCP unter Retransmits leidet – oder umgekehrt.

Das eigentliche Problem: Traffic-Form ist wichtiger als Spitzenbandbreite

Die Übertragbarkeit von iperf hängt davon ab, ob der Test die Traffic-Form des realen Workloads trifft. Wichtige Dimensionen sind:

Wenn Ihr Workload zu 80 % aus kleinen Requests besteht, sind reine Throughput-Werte meist nicht der limitierende Faktor. Dann zählen Latenz, Tail-Latency, Queueing und Stabilität unter Peak-Last.

Latenz und Tail-Latency: Der blinde Fleck klassischer iperf-Setups

iperf eignet sich hervorragend, um Bandbreite zu messen. Für Latenz ist es nur bedingt geeignet, weil es primär Daten schiebt, nicht „Antwortzeiten“ auf Anwendungsebene modelliert. In realen Systemen sind jedoch gerade die Perzentile entscheidend: P95/P99-Latenz und Timeout-Rate. Ein Netzwerkpfad kann hohen Durchsatz liefern und trotzdem schlechte P99-Latenz haben, etwa durch Queueing in Gateways, Traffic Shaping, Bufferbloat oder überlastete NAT/Conntrack-Subsysteme.

Kubernetes-Effekte: Der Pfad ist länger als viele denken

In Kubernetes ist „Netzwerkpfad“ selten nur ein Kabel oder ein VPC-Link. Selbst in scheinbar einfachen Setups kommen Komponenten dazu, die iperf in einem nackten VM-Setup nicht abbildet:

Das bedeutet: Ein iperf-Test „Pod zu Pod“ kann etwas anderes messen als „Node zu Node“ oder „VM zu VM“. Wenn Sie iperf nutzen, sollten Sie den Testpunkt bewusst wählen: innerhalb des Pods, auf dem Node, oder außerhalb des Clusters. Hintergrund zu Kubernetes-Netzwerkmodellen: Kubernetes Networking Concepts.

MTU und Offloading: Warum ein guter iperf-Wert trotzdem „komische“ Fehler zulässt

Ein häufiger Praxisfall: iperf zeigt hohe Bandbreite, aber echte Anwendungen sehen TLS-Handshake-Probleme, gRPC-Stream-Abbrüche oder „Small works, large fails“. Das ist oft ein MTU-/PMTUD-Thema oder ein Offloading-Effekt. iperf kann mit bestimmten Defaults so testen, dass das Problem nicht sichtbar wird, oder es „glattgebügelt“ wirkt.

Wenn MTU im Spiel ist, reicht „Durchsatz ist hoch“ nicht. Sie müssen explizit mit unterschiedlichen Payload-Größen und realistischen TLS/HTTP-Patterns testen.

Warum „realer Workload“ nicht gleich „Production Traffic kopieren“ ist

Viele Teams reagieren auf iperf-Kritik mit dem Gegenextrem: „Dann testen wir eben mit echtem Traffic.“ Das klingt gut, ist aber in der Praxis riskant und methodisch oft schwach, weil Workloads nicht kontrolliert sind. Ein belastbarer Workload-Test ist eine Simulation mit reproduzierbaren Eigenschaften:

Dadurch wird der Test wiederholbar und vergleichbar – genau wie iperf, nur näher an der Realität.

Ein praxisnahes Testdesign: Baseline mit iperf, Validierung mit Workload-Simulation

In der Praxis ist ein zweistufiger Ansatz am zuverlässigsten. iperf liefert die Baseline, Workload-Tests zeigen die Übertragbarkeit und die echten Engpässe.

So vermeiden Sie, dass iperf „alles schönredet“, und ebenso, dass Workload-Tests ohne Baseline zu Interpretationsrätseln werden.

Wichtige iperf-Parameter, die in der Praxis den Unterschied machen

Viele falsche Schlüsse entstehen aus Defaults. Wenn Sie iperf als ernsthaften Baseline-Test nutzen wollen, sollten Sie mindestens diese Aspekte bewusst setzen:

Dokumentieren Sie Parameter und Umgebung (CNI-Modus, Encapsulation, MTU, Sidecars), sonst sind Zahlen später kaum vergleichbar.

Wie Sie die Lücke zwischen „iperf Durchsatz“ und „App Throughput“ quantifizieren

Um Diskussionen zu entemotionalisieren, hilft eine einfache Effizienzbetrachtung: Wie viel vom gemessenen Rohdurchsatz nutzt die Anwendung tatsächlich? Das ist kein „Schuldwert“, sondern ein Diagnoseanker. Ein vereinfachtes Verhältnis:

Effizienz = Throughput_real Throughput_iperf

Wenn die Effizienz niedrig ist, ist das nicht automatisch ein Netzwerkproblem. Häufige Ursachen sind TLS-CPU, schlechte Request-Pipeline, zu kleine Fenster, ungünstige Connection-Pools, Proxy-Overhead oder zu aggressive Retries. Die Kennzahl hilft aber, die Frage zu strukturieren: „Ist der Pfad grundsätzlich schnell, aber die Anwendung nutzt ihn schlecht – oder ist der Pfad selbst instabil?“

Typische Szenarien, in denen iperf besonders irreführend sein kann

Wie ein realistischer Workload-Test aussehen kann, ohne unnötig kompliziert zu werden

Ein realistischer Test muss nicht sofort ein vollständiger Lasttest im Stil eines Benchmarks sein. Entscheidend ist, dass er die kritischen Merkmale Ihres Verkehrs abbildet. Ein minimal-pragmatisches Muster ist:

Für viele Teams ist es hilfreich, diesen Workload-Test sowohl „ohne Cluster-Komplexität“ (z. B. zwei VMs) als auch „im echten Kubernetes-Pfad“ (Pod↔Service↔Pod, mit Sidecars) zu fahren. Nur so sehen Sie, welcher Anteil der Differenz aus Kubernetes/Policy/Proxy stammt.

Interpretation: Welche Aussagen Sie aus iperf sicher ableiten können

iperf ist trotz aller Grenzen ein wertvolles Werkzeug, wenn Sie es richtig einordnen. Die folgenden Aussagen sind in der Regel belastbar, sofern Testpunkt und Parameter sauber dokumentiert sind:

Die Aussagen, die Sie nicht automatisch treffen sollten, sind: „Die Anwendung muss das auch schaffen“ oder „das Netzwerk ist sicher nicht schuld“. Dafür brauchen Sie den Workload-Test.

Outbound-Quellen für vertiefende Informationen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version