Network-Performance-Tests: iperf vs. realer Workload

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.

• Rohdurchsatz: Wie viel Traffic schafft der Pfad unter idealisierten Bedingungen?
• Stabilität: Gibt es Drops, Jitter, starke Schwankungen über die Zeit?
• Skalierung über Parallelströme: Wird ein Link erst mit mehreren Flows „voll“?
• Vergleichbarkeit: Gleiche Parameter liefern vergleichbare Ergebnisse zwischen Umgebungen.

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:

• Durchsatz = Performance: Ein hoher iperf-Durchsatz bedeutet nicht automatisch niedrige Latenz oder gute P99.
• Ein Flow repräsentiert viele: Ein einzelner TCP-Stream verhält sich anders als tausende parallele, kurzlebige Verbindungen.
• Netzwerk ist isoliert: In Produktion sind CPU, Kernel, TLS, Sidecars und Load Balancer Teil des Pfads.

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:

• Congestion Control: Algorithmus und Fensterwachstum beeinflussen, wie schnell Durchsatz erreicht wird.
• Buffering: Große Socket-Buffer und Kernel-Queues können „schöne“ Zahlen erzeugen, während reale Apps früher backpressuren.
• Ein- oder Mehrstrom: Viele Pfade sind per Flow limitiert (ECMP, Shaping, Policer), daher wirkt Parallelität künstlich.

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:

• Verbindungsdauer: lange Streams vs. kurze Requests
• Payload-Größen: viele kleine Nachrichten vs. wenige große Transfers
• Richtung: symmetrisch vs. stark einseitig (z. B. Log-Shipping, Replikation)
• Burstiness: konstant vs. burstig (z. B. Cronjobs, Batch, Autoscaling)
• Parallelität: wenige „fette“ Flows vs. viele „dünne“ Flows

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.

• Symptom: iperf zeigt hohe Bandbreite, aber APIs haben Timeouts.
• Ursache: Queues und Jitter, nicht unbedingt „zu wenig Bandbreite“.
• Konsequenz: Tests müssen neben Durchsatz auch Latenz unter Last betrachten.

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:

• CNI-Datapath: eBPF oder iptables/ipvs, ggf. Encapsulation (VXLAN/Geneve)
• Service-Load-Balancing: kube-proxy oder eBPF-Service-Translation
• NetworkPolicies: zusätzliche Filterregeln und Match-Kosten
• Sidecars/Proxies: mTLS, Envoy-Queues, zusätzliche Hop-Latenz
• Masquerade/NAT: Conntrack-State und Port-Nutzung

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.

• MTU-Mismatch: große Payloads fragmentieren oder droppen, besonders bei Tunneln und Verschlüsselung.
• PMTUD blockiert: ICMP-„Packet Too Big“ wird gefiltert, Retransmits steigen, bis Timeouts auftreten.
• Offloading: GRO/GSO/TSO kann Messbilder verändern, besonders in Captures und bei Interpretation.

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:

• Definierte Request-Mixe: z. B. 70 % kleine Reads, 20 % Writes, 10 % große Responses
• Definierte Parallelität: Anzahl Clients, Concurrency pro Client, Ramp-up
• Definierte Payload-Verteilung: nicht nur Durchschnitt, sondern auch große Ausreißer
• Definierte Erfolgsmetriken: P95/P99, Timeout-Rate, Fehlerklassen, Retries

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.

• Stufe 1: iperf Baseline (Node↔Node, Pod↔Pod, ggf. Cross-Cluster) mit klar dokumentierten Parametern
• Stufe 2: Workload-Tests mit realistischen Protokollen (HTTP/2, gRPC, TLS), Payload-Mix und Concurrency
• Stufe 3: Engpass-Isolation (CPU-Limits, Sidecar an/aus, Policy an/aus, NAT-Pfad ändern)

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:

• Dauer: kurz genug für Reproduzierbarkeit, lang genug für stabile Congestion Control (Warm-up berücksichtigen)
• Parallel Streams: 1 und mehrere Werte testen, weil reale Workloads oft parallelisieren
• Richtung: beide Richtungen testen, weil Asymmetrie (Egress vs. Ingress) häufig ist
• UDP nur gezielt: sinnvoll für Jitter/Loss, aber nicht als Ersatz für TCP-Realität
• Testpunkt: Pod↔Pod vs. Node↔Node vs. extern – das misst unterschiedliche Pfade

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:

$\mathrm{Effizienz}=\frac{\mathrm{Throughput\_real}}{\mathrm{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

• Viele kurze Verbindungen: iperf misst lange Streams; reale Workloads zahlen Connection-Overhead (TCP+TLS) ständig neu.
• gRPC/HTTP/2 mit Backpressure: reale Protokolle drosseln bewusst; iperf drückt konstant.
• Load Balancer und Idle Timeouts: reale Verbindungen werden getrennt, iperf läuft oft „glatt“ durch.
• NAT/Conntrack-Limits: viele parallele Flows kippen Conntrack; iperf mit wenigen Flows bleibt stabil.
• Policy- oder eBPF-Regeln: Match-Kosten und Drops treffen bestimmte Ports/Flows; iperf-Flow ist nicht repräsentativ.
• MTU/PMTUD: Probleme treten erst bei bestimmten Payload-Größen oder TLS-Records auf.

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:

• Protokolltreue: Testen Sie mit dem Protokoll, das Sie produktiv nutzen (z. B. HTTPS, HTTP/2, gRPC).
• Payload-Verteilung: nicht nur „eine Größe“, sondern klein/mittel/groß wie im echten Betrieb.
• Concurrency + Ramp-up: Last langsam steigern, um Kipppunkte zu finden (Queues, Timeouts, Retries).
• Messung der Perzentile: P50/P95/P99 plus Fehler- und Retry-Raten.
• Vergleichbarkeit: identische Parameter pro Testlauf, klare Versionierung der Testkonfiguration.

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:

• Kapazitätsbaseline: Der Pfad kann unter idealisierten Bedingungen mindestens X Mbit/s liefern.
• Instabilitätssignale: starke Schwankungen, Drops (UDP) oder viele Retransmits (TCP) deuten auf Probleme hin.
• Flow-Limitierung: wenn ein Stream niedrig ist, mehrere Streams aber deutlich höher, ist der Pfad möglicherweise per Flow limitiert.
• Vergleich über Änderungen: Vorher/Nachher bei CNI-Änderungen, MTU-Anpassungen, Gateway-Rollouts.

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

• iperf3: Dokumentation, Optionen und Output-Interpretation
• Kubernetes Networking Concepts: Datenpfade und CNI-Einordnung
• Kubernetes Services: Service-Routing und Lastverteilung im Cluster
• Kubernetes DNS: Service Discovery als Performance-Faktor

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.