Hvor mange kerner har OpenVPN brug for? Det afhænger af vejen

To servere med samme antal processorer kan holde meget forskellig gennemstrømning, fordi det tal, der betyder noget, er hvor mange kerner den aktive datasti faktisk kan bruge. En enkelt daemon i brugerrummet, der behandler en klients pakker, er begrænset af én kerne, mens en offloadet kernevej kan sprede det arbejde. Ingen af de to udsagn fortæller, hvad en given maskine vil gøre for din trafik, og derfor kommer måling før kernetælling.

Sammenligningen nedenfor handler om, hvor pakkerne behandles, ikke om hvilket produkt der er hurtigst i abstrakt forstand. Det er to forskellige spørgsmål med forskellige svar.

Én kerne per strøm på brugerrumsvejen

I en traditionel Community OpenVPN instans behandles datakanalen i brugerrummet, og en travl forbindelse kan låse én processor, mens den samlede maskinudnyttelse forbliver udramatisk. Det er derfor, at flere kerner på en vært, der allerede er mættet på én strøm, ikke ændrer noget: planlæggeren har ingen måde at dele det arbejde. Strukturen med én proces per klient begrænser én klients overførsel til én kernes kapacitet, uanset det samlede kernetal. Læs udnyttelsen per kerne under en test i stedet for det samlede tal, ellers vil flaskehalsen se ud som ledig kapacitet.

At køre flere serverinstanser på én vært fordeler forskellige klienter på tværs af processer. Det paralleliserer ikke en eksisterende forbindelse og koster separate puljer, lyttere og rutningsbeslutninger.

Den anden vej: pakker i kernen

Offload af datakanalen flytter understøttet pakkebehandling og kryptografi ind i kernen, hvor arbejdet kan bruge flere kerner. Det ændrer kapacitetsspørgsmålet fra én kerne til maskinen, men kun for konfigurationer, som implementeringen understøtter: et kompatibelt kernemodul, en kvalificeret dataciffer og en konfiguration uden de funktioner, som offload udelukker. At installere et modul er ikke det samme som at bruge det, så bekræft den aktive tilstand ud fra forbindelsens egen log eller statusoutput. Et versionsbanner beviser, hvad der er tilgængeligt, ikke hvad der kører.

Offload fjerner ikke godkendelse eller kontrolkanalen, og det gør ikke hver udrulning til en flerkernet. Det er lokal acceleration af en kompatibel datasti, og kravene varierer efter platform og version.

Hvad sammenligningen egentlig afgør

Den reelle valgmulighed er mellem at acceptere et loft per strøm, at sprede klienter over instanser og at skifte til en understøttet offload-konfiguration. Hver især løser et forskelligt problem, og at vælge den forkerte koster penge uden at flytte tallet. Den test, der betyder noget, er den, der er formet som den måde, tjenesten bruges på.

Mål tre former: én klient med én overførsel, én klient med flere strømme og flere klienter sammen. Et højt samlet tal i den tredje beviser ikke, at en enkelt download kan nå det, og en langsom enkelt overførsel beviser ikke, at serveren har opbrugt sin samlede kapacitet. Resultaterne svarer på forskellige spørgsmål, og begge er værd at have.

Kun den midterste form fortæller, om samtidighed inde i én klient hjælper, hvilket normalt er en egenskab ved transporten og vejen snarere end ved serveren. Kun den første fortæller det loft, en enkelt applikation vil se. Hold arbejdsbyrden identisk mellem kørslerne, så sammenligningen betyder noget.

At måle så tallet betyder noget

Notér serverens og klientens versioner, den aktive datasti, den forhandlede dataciffer, overførselsretningen, pakkestørrelser, antal strømme og varighed. Overvåg aktivitet per kerne og pakke- og køtab i begge ender, fordi klientens eget interface, udbyderens netværk eller destinationsservicen kan blive grænsen først. Ændr én variabel ad gangen, da en kørsel, der ændrer ciffer, komprimering, MTU og offload på samme tid, ikke kan fortælle, hvilken der betød noget. Behold den adgangspolitik, du faktisk har til hensigt at udrulle, under testen, fordi en laboratorieopsætning, ingen vil køre, beviser lidt.

Efterlad derefter plads til kontrolkanalen, til genforhandling og til alt andet, der kører på værten.

Rapportér, hvad konfigurationen holdt under den tilsigtede samtidighed, i stedet for en hastighed ekstrapoleret fra andres hardware. Et tal med dets testbetingelser vedhæftet er nyttigt; et løfte uden dem er et gæt, der vil blive citeret tilbage til dig.