Hvor mange kjerner trenger OpenVPN? Det avhenger av veien

To servere med samme antall prosessorer kan opprettholde svært ulik gjennomstrømning, fordi tallet som betyr noe er hvor mange kjerner den aktive databanen faktisk kan bruke. En enkelt daemon i brukerrommet som behandler pakkene til én klient er begrenset til én kjerne, mens en offloadet kjernevei kan spre det arbeidet. Ingen av de to utsagnene sier hva en gitt maskin vil gjøre med trafikken din, derfor kommer målingen før kjerneantallet.

Sammenligningen nedenfor handler om hvor pakkene behandles, ikke om hvilket produkt som er raskest i abstrakt forstand. Det er forskjellige spørsmål med forskjellige svar.

Én kjerne per strøm på brukerromsveien

I en tradisjonell Community OpenVPN instans behandles datakanalen i brukerrommet, og en travel forbindelse kan låse én prosessor mens den samlede maskinutnyttelsen forblir upåfallende. Derfor endrer det ingenting å legge til kjerner på en vert som allerede er mettet på én strøm: planleggeren har ingen måte å dele det arbeidet på. Strukturen med én prosess per klient begrenser én klients overføring til kapasiteten til én kjerne, uansett totalt kjerneantall. Les utnyttelsen per kjerne under en test i stedet for totaltallet, ellers vil flaskehalsen se ut som ledig kapasitet.

Å kjøre flere serverinstanser på én vert fordeler separate klienter på tvers av prosesser. Det paralleliserer ikke en eksisterende forbindelse, og det koster separate puljer, lyttere og rutingsbeslutninger.

Den andre veien: pakker i kjernen

Offload av datakanalen flytter støttet pakkebehandling og kryptografi inn i kjernen, der arbeidet kan bruke flere kjerner. Det endrer kapasitetsspørsmålet fra én kjerne til maskinen, men bare for konfigurasjoner som implementasjonen støtter: en kompatibel kjernemodul, en kvalifisert datachiffer og en konfigurasjon uten funksjonene offload utelukker. Å installere en modul er ikke det samme som å bruke den, så bekreft den aktive modusen fra forbindelsens egen logg eller statusutskrift. Et versjonsbanner beviser hva som er tilgjengelig, ikke hva som kjører.

Offload fjerner ikke autentisering eller kontrollkanalen, og det gjør ikke hver utrulling flerkjernet. Det er lokal akselerasjon av en kompatibel databane, og kravene varierer etter plattform og versjon.

Hva sammenligningen faktisk avgjør

Det virkelige valget står mellom å akseptere et tak per strøm, å spre klienter over instanser og å gå over til en støttet offload-konfigurasjon. Hver av dem løser et annet problem, og å velge feil koster penger uten å flytte tallet. Testen som betyr noe er den som er formet som måten tjenesten brukes på.

Mål tre former: én klient med én overføring, én klient med flere strømmer og flere klienter sammen. Et høyt totaltall i den tredje beviser ikke at én enkelt nedlasting kan nå det, og en treg enkelt overføring beviser ikke at serveren har brukt opp den samlede kapasiteten. Resultatene svarer på forskjellige spørsmål, og begge er verdt å ha.

Bare den midterste formen forteller deg om samtidighet inne i én klient hjelper, noe som vanligvis er en egenskap ved transporten og veien og ikke ved serveren. Bare den første forteller taket en enkelt applikasjon vil se. Hold arbeidsbelastningen identisk mellom kjøringene slik at sammenligningen betyr noe.

Å måle slik at tallet betyr noe

Noter versjonene til server og klient, den aktive databanen, den forhandlede datachifferen, overføringsretningen, pakkestørrelser, antall strømmer og varighet. Følg med på aktivitet per kjerne og pakke- og køtap i begge ender, fordi klientens eget grensesnitt, leverandørens nettverk eller tjenesten på destinasjonen kan bli grensen først. Endre én variabel om gangen, siden en kjøring som endrer chiffer, komprimering, MTU og offload samtidig ikke kan fortelle deg hvilken som betydde noe. Behold tilgangspolicyen du faktisk har tenkt å rulle ut, under testen, fordi et laboratorioppsett ingen vil kjøre beviser lite.

Deretter lar du det være plass til kontrollkanalen, til reforhandling og til alt annet som kjører på verten.

Rapporter hva konfigurasjonen holdt under den tiltenkte samtidigheten, i stedet for en hastighet ekstrapolert fra andres maskinvare. Et tall med testbetingelsene sine vedlagt er nyttig; et løfte uten dem er en gjetning som vil bli sitert tilbake til deg.