Auf dieser Seite
Das Wichtigste
- Beide Größen erfassenGbit/s zählt Bits pro Sekunde; Pakete/s zählt verarbeitete Pakete.
- Die Messgrenze nennenIP-Bytezähler, Ethernet-Framezähler und theoretische Leitungsraten sind nicht austauschbar.
- Belege zusammen mit Zahlen aufbewahrenFramegrößen, Richtung, aktive Funktionen und beobachtete Verluste machen Ergebnisse verständlich.
Zwei Zähler beschreiben unterschiedliche Anforderungen
Gbit/s gibt eine Bitrate an, Pakete/s die Anzahl von Paketen pro Zeit. Ein Link transportiert Bytes, doch Weiterleitung und Filterung erledigen auch Arbeit pro Paket: Parsing, Suchen, Queues, Zähler und Zustandsverwaltung. Die Paketgröße ist deshalb beim Vergleich zweier Verkehrsmuster entscheidend.
Notieren Sie Messintervall und Richtung. Eine Empfangsspitze von einer Sekunde ist nicht unmittelbar mit einem Fünf-Minuten-Mittel beider Richtungen vergleichbar. Ein Aggregat mehrerer Links kann denselben Verkehr mehrfach zählen. Klären Sie vor einer Kapazitätsdiagnose, was das Diagramm überhaupt erfasst.
Geringe Bandbreite schließt einen Paketverarbeitungsengpass nicht aus. Hohe Bandbreite beweist umgekehrt keinen CPU-Engpass. Vergleichen Sie Raten mit Verlusten, Queue-Druck und Anwendungsverhalten an der relevanten Grenze.
Eine eindeutige Frame-Definition für die Umrechnung verwenden
Der Peeryx-Rechner verwendet eine Ethernet-Framelänge einschließlich FCS und addiert 20 Byte-Zeiten für Präambel, Startbegrenzung und Abstand zwischen Frames. Unter dieser Konvention gilt: PPS = Bit/s ÷ [8 × (Frame-Bytes + 20)].
Das ist eine Leitungsratenrechnung für eine definierte Framegröße, kein Anwendungsdurchsatz und kein Hardwaretest. Ein IP-Bytezähler kann Ethernet-Header und FCS auslassen. Auch Mitschnitte können FCS auslassen oder durch Offloads beeinflusste Pakete zeigen. Eine unerklärte Zählerzahl wird durch die Formel nicht zu einer Messung.
VLAN-Tags, Kapselung und gemischte Paketgrößen ändern die Bilanz. Stellen Sie die Definition neben die Zahl und planen Sie mit einer repräsentativen Verteilung. Eine einzige Durchschnittsgröße kann kurze Phasen mit überwiegend kleinen Paketen verdecken.
Zwei hypothetische Beispiele mit nachvollziehbarer Rechnung
Dies sind Rechenbeispiele, keine Kundenfälle oder Peeryx-Leistungsmessungen. Bei 10 Gbit/s belegen 64-Byte-Ethernet-Frames nach dieser Konvention jeweils 84 Byte-Zeiten: theoretisch etwa 14,88 Millionen Frames/s. Bei derselben Bitrate benötigen 1.518-Byte-Frames jeweils 1.538 Byte-Zeiten und ergeben ungefähr 0,81 Millionen Frames/s.
Der Strom kleiner Frames enthält damit etwa 18,3-mal so viele Frames bei identischer Leitungsbitrate. Daraus folgt keine gleich große CPU-Steigerung: Implementierung, Funktionen, Verkehrsverteilung und Hardware beeinflussen den Aufwand. Es zeigt jedoch, warum Bandbreite allein keinen Lastvergleich erlaubt.
Ein weiteres hypothetisches Beispiel: 12 Millionen 64-Byte-Frames/s entsprechen unter dieser Konvention 8,064 Gbit/s auf der Leitung. Zeigt ein Diagramm etwas anderes, vergleichen Sie zuerst Abtastung, Richtung und Byte-Zählgrenze. Erfinden Sie keine Gerätegrenze, damit zwei ungleiche Zähler zusammenpassen.
| Hypothetische Leitungsrate | Ethernet-Frame einschließlich FCS | Frame plus 20 Byte-Zeiten | Theoretische Rate |
|---|---|---|---|
| 10 Gbit/s | 64 Byte | 84 Byte-Zeiten | 14,88095 Mpps |
| 10 Gbit/s | 1.518 Byte | 1.538 Byte-Zeiten | 0,81274 Mpps |
| 100 Gbit/s | 64 Byte | 84 Byte-Zeiten | 148,80952 Mpps |
Die erste begrenzende Stelle im Pfad finden
Vergleichen Sie Upstream-Nutzung, physische Interface-Verluste, NIC-Queuezähler, Weiterleitungsressourcen und Anwendungssymptome im selben Zeitraum. Gehen Pakete vor dem Host verloren, kann eine Anwendungseinstellung sie nicht zurückholen. Ist eine Queue überlastet, obwohl der Link Reserven hat, löst ein schnellerer Port dieses Problem nicht zwangsläufig.
Eine mittlere CPU-Auslastung kann ungleiche Verteilung verbergen. Prüfen Sie verfügbare Daten pro Kern oder Queue und den verwendeten Empfangspfad. RSS und verwandte Linux-Mechanismen verteilen Arbeit unterschiedlich; Änderungen müssen zu Treiber, virtueller oder physischer NIC und Anwendung passen. Mehr Queues liefern nicht automatisch bessere Ergebnisse.
Neue Verbindungen, Fragmente und aufwendig zu prüfender Verkehr können Last erzeugen, die Pakete/s allein unzureichend beschreibt. Bewahren Sie aktive Funktionen und Verkehrseigenschaften im Vorfallsprotokoll auf. Eine Messung mit deaktiviertem Filter ist keine Filterkapazität.
Mitigation dort einsetzen, wo sie den Engpass entlastet
Ist ein Upstream-Link der Engpass, muss Verkehr vor diesem Link reduziert werden, um nutzbare Kapazität zu erhalten. Lokale Filter können eine andere Aufgabe erfüllen, transportieren aber keine Pakete durch einen gesättigten Upstream. Geschützter Transit und bedarfsgesteuerte Umleitung haben eigene Übergabe- und Aktivierungsbedingungen.
Ist die Paketverarbeitung der Engpass, prüfen Sie vermeidbare Arbeit und die Anforderungen legitimen Verkehrs. Frühe Filterung, einfachere Richtlinien oder eine andere Arbeitsverteilung können helfen, benötigen aber eine gemessene Abnahme. Eine Regel, die viele Pakete entfernt, kann bei zu weitem Umfang auch legitimen Verkehr verwerfen.
Defense Fabric ist Software für kompatible, vom Betreiber kontrollierte Hardware. Lizenz und deklarierte Ports sind kein allgemeiner Mpps-Benchmark. Lokaler Server, aktive Funktionen und Netzpfad bestimmen den Validierungsbedarf. Trennen Sie diese Größe von gemeinsam genutzter Anbieternetzkapazität.
Einen nachvollziehbaren Testplan aufstellen
Überlastungsbenchmarks gehören in eine isolierte, autorisierte Umgebung. RFC 6815 begrenzt die Anwendung von RFC-2544-Methoden auf Produktionsnetzen ausdrücklich. Laufende Dienstbeobachtung und genehmigte Anwendungsabnahme verfolgen einen anderen Zweck als ein Gerät bis zum Paketverlust zu treiben.
Erfassen Sie Hardware- und Softwareversionen, Richtung, angebotenen und empfangenen Verkehr, Framegrößen oder Verteilung, Flow-Vielfalt, aktive Richtlinien, Dauer und Verluste. Bewahren Sie Anwendungsergebnisse zusammen mit Netzzählern auf. Nennen Sie nicht getestete Host-, Link- und Umschaltabhängigkeiten.
Ein wiederholbares Ergebnis stützt eine bestimmte Konfiguration unter angegebenen Bedingungen. Portbezeichnung, einzelner Kurztest und theoretische Umrechnung erlauben engere Schlussfolgerungen. Halten Sie diese Unterschiede bei Beschaffung und Kapazitätsplanung sichtbar.
Schlussfolgerungen vermeiden, die Zähler nicht belegen
- Vergleichen Sie keine IP-Byterate mit einer Ethernet-Leitungsrate, ohne die Messgrenzen abzugleichen.
- Addieren Sie Empfang und Senden nicht zu einer vermeintlichen Weiterleitungskapazität in nur einer Richtung.
- Leiten Sie kein Ergebnis für kleine Pakete aus einem Großpakettest ab und keine Filterleistung aus ungefilterter Weiterleitung.
- Beschreiben Sie ein Rechenbeispiel nicht als beobachteten Kundenfall oder gemessene Softwareleistung.
- Nehmen Sie nicht an, dass ein schnellerer Port einen Queue-, Zustandstabellen- oder Anwendungsengpass behebt.
Fragen zu Paketrate und Schutzkapazität
Bedeutet eine höhere Mpps-Zahl immer besseren Schutz?
Nur vergleichbare Messungen stützen einen solchen Vergleich. Prüfen Sie Größe und Mischung des Verkehrs, Richtung, Funktionen, Verluste und Bedingungen. Eine theoretische Leitungsgrenze und gemessene Filterleistung beantworten verschiedene Fragen.
Kann ich Gbit/s ohne Paketgröße in Mpps umrechnen?
Nicht in einen einzelnen aussagekräftigen Wert. Sie brauchen eine Größe oder Verteilung und eine klare Byte-Zählkonvention. Ist die reale Verteilung unbekannt, verwenden Sie einen Bereich relevanter Größen.
Misst der Rechner meinen Server?
Nein. Er rechnet transparent mit Ihren Eingaben. Server- und Filterkapazität benötigen eigene Messungen mit definierter Konfiguration und Abnahmekriterien.
