Op deze pagina
Kernpunten
- Leg beide dimensies vastGbit/s meet bits per seconde; pakketten/s telt verwerkte pakketten.
- Benoem de meetgrensEen IP-byteteller, Ethernet-frameteller en schatting op de lijn zijn niet uitwisselbaar.
- Bewaar bewijs bij de cijfersFramegroottes, richting, actieve functies en gemeten verlies maken een resultaat uitlegbaar.
Twee tellers beschrijven verschillende belasting
Gbit/s drukt een bitsnelheid uit, pakketten/s telt pakketten in de tijd. Een link vervoert bytes, maar doorsturen en filteren kosten ook werk per pakket: analyse, opzoekingen, wachtrijen, tellers en toestandsbeheer. Daarom is pakketgrootte belangrijk bij het vergelijken van verkeer.
Noteer interval en richting bij elke waarde. Een ontvangstpiek van één seconde is niet direct vergelijkbaar met een vijfminutengemiddelde van beide richtingen. Een totaal over meerdere links kan hetzelfde verkeer meermaals tellen. Bepaal vóór een capaciteitsdiagnose wat de grafiek precies telt.
Lage bandbreedte sluit een pakketverwerkingsknelpunt niet uit. Hoge bandbreedte bewijst evenmin een CPU-knelpunt. Vergelijk snelheden met verliezen, wachtrijdruk en toepassingsgedrag bij de relevante grens.
Gebruik een expliciete framelengte bij het omrekenen
De Peeryx-rekentool gebruikt een Ethernet-frame inclusief FCS en voegt 20 byte-tijden toe voor preambule, startafbakening en ruimte tussen frames. Volgens die afspraak: PPS = bits/s ÷ [8 × (framebytes + 20)].
Dit is een berekening op de lijn voor een opgegeven framegrootte, geen nuttige toepassingsdoorvoer of hardwaretest. Een IP-byteteller kan Ethernet-headers en FCS weglaten. Een opname kan eveneens FCS weglaten of door offloads beïnvloede pakketten tonen. De formule maakt van een onverklaarde teller geen meting.
VLAN-tags, inkapseling en gemengde pakketgroottes veranderen de berekening. Plaats de definitie bij het cijfer en gebruik een representatieve verdeling voor echt verkeer. Eén gemiddelde grootte kan korte perioden met vooral kleine pakketten verbergen.
Twee hypothetische voorbeelden met herhaalbare berekeningen
Dit zijn rekenvoorbeelden, geen klantincidenten of Peeryx-prestatiemetingen. Bij 10 Gbit/s nemen Ethernet-frames van 64 bytes ieder 84 byte-tijden in volgens deze afspraak: theoretisch ongeveer 14,88 miljoen frames per seconde. Frames van 1.518 bytes gebruiken bij dezelfde bitsnelheid 1.538 byte-tijden en leveren ongeveer 0,81 miljoen frames per seconde.
De stroom kleine frames bevat dus ongeveer 18,3 keer zoveel frames bij dezelfde bitsnelheid op de lijn. Dat voorspelt geen identieke CPU-toename: implementatie, functies, verkeersverdeling en hardware spelen mee. Het laat wel zien waarom alleen bandbreedte onvoldoende is voor een vergelijking.
Nog een hypothetische vergelijking: 12 miljoen frames van 64 bytes per seconde vertegenwoordigen volgens deze afspraak 8,064 Gbit/s op de lijn. Toont een grafiek iets anders, vergelijk dan eerst bemonstering, richting en bytegrenzen. Verzin geen apparaatlimiet om ongelijke tellers passend te maken.
| Hypothetische lijnsnelheid | Ethernet-frame inclusief FCS | Frame plus 20 byte-tijden | Theoretische snelheid |
|---|---|---|---|
| 10 Gbit/s | 64 bytes | 84 byte-tijden | 14,88095 Mpps |
| 10 Gbit/s | 1.518 bytes | 1.538 byte-tijden | 0,81274 Mpps |
| 100 Gbit/s | 64 bytes | 84 byte-tijden | 148,80952 Mpps |
Vind het eerste knelpunt in het pad
Vergelijk upstreamgebruik, fysieke interfaceverliezen, NIC-wachtrijen, doorvoermiddelen en toepassingssymptomen over dezelfde periode. Gaan pakketten vóór de host verloren, dan haalt een toepassingsinstelling ze niet terug. Is een wachtrij vol terwijl de link ruimte heeft, dan helpt een snellere poort niet noodzakelijk tegen die wachtrij.
Gemiddeld CPU-gebruik kan een scheve verdeling verbergen. Bekijk gegevens per core of wachtrij en bepaal het gebruikte ontvangstpad. RSS en verwante Linux-mechanismen verdelen werk anders; een wijziging moet passen bij driver, virtuele of fysieke NIC en toepassing. Meer wachtrijen leveren niet automatisch betere resultaten.
Nieuwe verbindingen, fragmenten en verkeer dat kostbaar beleid activeert kunnen belasting veroorzaken die pakketten/s niet volledig beschrijft. Bewaar actieve functies en verkeerseigenschappen in het incidentverslag. Een getal gemeten zonder filters is geen filtercapaciteit.
Plaats mitigatie waar deze het knelpunt kan verlichten
Is de upstreamverbinding het knelpunt, dan moet verkeer vóór die verbinding worden verminderd om bruikbare capaciteit te bewaren. Lokale filters kunnen een andere rol houden, maar vervoeren geen pakketten door een verzadigde upstream. Beschermde transit en omleiding op aanvraag hebben eigen leverings- en activeringsvoorwaarden.
Is pakketverwerking het knelpunt, onderzoek dan vermijdbaar werk en de behoeften van legitiem verkeer. Vroeg filteren, eenvoudiger beleid of andere werkverdeling kan helpen, maar vraagt een gemeten acceptatietest. Een regel die veel pakketten verwijdert kan bij te ruime selectie ook legitiem verkeer verwijderen.
Defense Fabric is software voor compatibele apparatuur onder beheer van de operator. Licentie en gedeclareerde poorten zijn geen universele Mpps-benchmark. Server, actieve functies en netwerkpad bepalen wat gevalideerd moet worden. Onderscheid dit van gedeelde netwerkcapaciteit bij een leverancier.
Schrijf een testplan dat begrijpelijke resultaten oplevert
Gebruik een geïsoleerde, geautoriseerde omgeving voor overbelastingsbenchmarks. RFC 6815 begrenst het gebruik van RFC-2544-methoden in productienetwerken expliciet. Gewone dienstobservatie en een goedgekeurde toepassingstest hebben een ander doel dan een apparaat tot verlies belasten.
Noteer hardware- en softwareversies, richting, aangeboden en ontvangen verkeer, framegroottes of verdeling, flowdiversiteit, actief beleid, duur en verliezen. Bewaar toepassingsuitkomsten naast netwerktellers. Geef aan wat niet is getest, inclusief host-, link- en omschakelafhankelijkheden.
Een herhaalbaar resultaat onderbouwt een bepaalde configuratie onder vermelde omstandigheden. Een poortlabel, een korte proef en een theoretische omrekening rechtvaardigen beperktere conclusies. Houd dat onderscheid zichtbaar bij inkoop en capaciteitsplanning.
Vermijd conclusies die tellers niet onderbouwen
- Vergelijk geen IP-bytesnelheid met een Ethernet-lijnschatting zonder de meetgrenzen gelijk te trekken.
- Tel ontvangst en verzending niet op om het totaal als capaciteit in één richting te presenteren.
- Leid geen resultaat voor kleine pakketten af uit een grootpakkettest, of filtercapaciteit uit ongefilterde doorvoer.
- Beschrijf een rekenvoorbeeld niet als waargenomen klantincident of gemeten softwareprestatie.
- Veronderstel niet dat een grotere poort een knelpunt in wachtrij, toestandstabel of toepassing oplost.
Vragen over pakketsnelheid en beschermingscapaciteit
Betekent een hoger Mpps-getal altijd betere bescherming?
Alleen vergelijkbare metingen ondersteunen die conclusie. Controleer grootte en mix, richting, functies, verlies en omstandigheden. Een theoretische lijngrens en gemeten filtering beantwoorden verschillende vragen.
Kan ik Gbit/s zonder pakketgrootte naar Mpps omrekenen?
Niet naar één zinvolle waarde. U heeft een grootte of verdeling en een duidelijke byteconventie nodig. Gebruik een reeks relevante groottes als de echte verdeling onbekend is.
Meet de rekentool mijn server?
Nee. De tool voert transparante berekeningen uit met uw invoer. Server- en filtercapaciteit vragen aparte metingen met vastgelegde configuratie en acceptatiecriteria.
