Kolik jader OpenVPN potřebuje? Záleží na cestě

Dva servery se stejným počtem procesorů mohou udržet velmi rozdílnou propustnost, protože rozhodující číslo je, kolik jader může aktivní datová cesta skutečně využít. Jediný démon v uživatelském prostoru, který zpracovává pakety jednoho klienta, je omezen jedním jádrem, zatímco odlehčená cesta v jádru může tuto práci rozdělit. Ani jedno z tvrzení neříká, co konkrétní stroj udělá s vaším provozem, a proto měření přichází před počítáním jader.

Srovnání níže se týká toho, kde se pakety zpracovávají, a ne toho, který produkt je v abstraktní rovině rychlejší. To jsou různé otázky s různými odpověďmi.

Jedno jádro na tok na cestě v uživatelském prostoru

V tradiční instanci Community OpenVPN se datový kanál zpracovává v uživatelském prostoru a vytížené spojení může zaměstnat jeden procesor, zatímco celkové vytížení stroje zůstává nenápadné. Právě proto přidání jader do hostitele, který je už nasycen jediným tokem, nic nezmění: plánovač nemá jak tuto práci rozdělit. Struktura jeden proces na klienta omezuje přenos jednoho klienta kapacitou jednoho jádra, ať je celkový počet jader jakýkoli. Během testu čtěte vytížení jednotlivých jader namísto souhrnného čísla, jinak bude překážka vypadat jako volná kapacita.

Spuštění několika instancí serveru na jednom hostiteli rozděluje oddělené klienty mezi procesy. Neparalelizuje jediné existující spojení a vyžaduje samostatné skupiny, přijímače a rozhodnutí o směrování.

Druhá cesta: pakety v jádru

Odlehčení datového kanálu přesouvá podporované zpracování paketů a kryptografii do jádra, kde práce může využít několik jader. Tím se otázka kapacity mění z jednoho jádra na stroj, ale jen u konfigurací, které implementace podporuje: kompatibilní modul jádra, vhodná datová šifra a konfigurace bez funkcí, které odlehčení vylučuje. Nainstalovat modul není totéž jako ho používat, proto ověřte aktivní režim z vlastního logu spojení nebo z výstupu stavu. Banner verze dokazuje, co je k dispozici, ne co běží.

Odlehčení neodstraňuje ověřování ani řídicí kanál a nepromění každé nasazení v mnohojádrové. Je to místní zrychlení kompatibilní datové cesty a požadavky se liší podle platformy a verze.

Co srovnání vlastně rozhoduje

Skutečná volba je mezi přijetím stropu na tok, rozdělením klientů mezi instance a přechodem na podporovanou konfiguraci s odlehčením. Každá řeší jiný problém a volba špatné stojí peníze, aniž by pohnula číslem. Test, na kterém záleží, je ten, který má tvar způsobu, jakým se služba používá.

Změřte tři tvary: jeden klient s jedním přenosem, jeden klient s několika toky a několik klientů společně. Vysoký součet ve třetím nedokazuje, že ho jedno stahování může dosáhnout, a pomalý jednotlivý přenos nedokazuje, že server vyčerpal celkovou kapacitu. Výsledky odpovídají na různé otázky a obojí má cenu.

Pouze prostřední tvar říká, zda pomáhá souběžnost uvnitř jednoho klienta, což je obvykle vlastnost přenosu a cesty, nikoli serveru. Pouze první říká strop, který uvidí jedna aplikace. Udržujte zátěž mezi běhy stejnou, aby srovnání něco znamenalo.

Měřit tak, aby číslo něco znamenalo

Zapište verze serveru a klienta, aktivní datovou cestu, vyjednanou datovou šifru, směr přenosu, velikosti paketů, počet toků a dobu trvání. Sledujte aktivitu jednotlivých jader a ztráty paketů a front na obou koncích, protože rozhraní samotného klienta, síť poskytovatele nebo cílový servis se mohou stát limitem jako první. Měňte vždy jednu proměnnou, protože běh, který mění šifru, komprimaci, MTU a odlehčení zároveň, vám neřekne, která byla důležitá. Během testu držte přístupovou politiku, kterou skutečně hodláte nasadit, protože laboratorní uspořádání, které nikdo nebude provozovat, dokazuje málo.

Potom nechte rezervu pro řídicí kanál, pro opakované vyjednávání a pro všechno ostatní, co na hostiteli běží.

Uveďte, co konfigurace udržela při zamýšlené souběžnosti, místo rychlosti odvozené z cizího hardwaru. Číslo s uvedenými podmínkami testu je užitečné; slib bez nich je odhad, který vám vrátí zpátky.