Kui palju tuumasid OpenVPN vajab? See sõltub teest

Kahel sama arvu protsessoritega serveril võib olla väga erinev läbilaskevõime, sest tähtis arv on see, kui mitut tuuma saab aktiivne andmetee tegelikult kasutada. Ühe kliendi pakette töötlev üksik kasutajaruumi deemon on piiratud ühe tuumaga, samas kui mahalaaditud kerneli tee võib selle töö laiali jaotada. Kumbki väide ei ütle, mida konkreetne masin teie liiklusega teeb, seepärast tuleb mõõtmine enne tuumade lugemist.

Allpool olev võrdlus käsitleb seda, kus pakette töödeldakse, mitte seda, milline toode on abstraktselt kiirem. Need on erinevad küsimused erinevate vastustega.

Üks tuum voo kohta kasutajaruumi teel

Traditsioonilises Community OpenVPN eksemplaris töödeldakse andmekanalit kasutajaruumis ja hõivatud ühendus võib kinni hoida ühe protsessori, samal ajal kui masina üldine kasutus jääb märkamatuks. Seepärast ei muuda tuumade lisamine hostile, mis on juba ühe voo peal küllastunud, midagi: planeerijal pole viisi selle töö jagamiseks. Kliendi kohta üks protsess struktuur piirab ühe kliendi ülekannet ühe tuuma võimsusega, olenemata tuumade koguarvust. Testi ajal lugege tuuma kohta kasutust, mitte kogunäitajat, muidu näib kitsaskoht vaba varuna.

Mitme serverieksemplari käitamine ühes hostis jaotab eraldi kliendid protsesside vahel. See ei rööpastanda olemasolevat ühendust ja nõuab eraldi ressursipoolid, kuulajaid ja marsruutimisotsuseid.

Teine tee: paketid kernelis

Andmekanali mahalaadimine viib toetatud paketitöötluse ja krüptograafia kerneli, kus töö saab kasutada mitut tuuma. See muudab võimsuse küsimuse ühest tuumast masinaks, kuid ainult konfiguratsioonide puhul, mida teostus toetab: ühilduv kerneli moodul, sobiv andmesifr ja konfiguratsioon ilma funktsioonideta, mida mahalaadimine välistab. Mooduli paigaldamine ei ole sama mis selle kasutamine, seega kinnitage aktiivne režiim ühenduse enda logist või olekuväljundist. Versioonibänner tõestab, mis on saadaval, mitte mis töötab.

Mahalaadimine ei eemalda autentimist ega juhtkanalit ja ei tee igast juurutusest mitmetuumalist. See on ühilduva andmetee kohalik kiirendus ja nõuded erinevad platvormi ning versiooni järgi.

Mida võrdlus tegelikult otsustab

Tegelik valik on voo kohta ülempiiri aktsepteerimise, klientide eksemplaride vahel jagamise ja toetatud mahalaadimiskonfiguratsioonile ülemineku vahel. Igaüks lahendab erinevat probleemi ja vale valimine maksab raha, liigutamata numbrit. Tähtis test on see, mis on kujundatud teenuse kasutamise viisi järgi.

Mõõtke kolme kuju: üks klient ühe ülekandega, üks klient mitme vooga ja mitu klienti korraga. Kõrge kogusumma kolmandas ei tõesta, et üks allalaadimine võib selle saavutada, ja aeglane üksikülekanne ei tõesta, et serveril on koguvõimsus otsas. Tulemused vastavad erinevatele küsimustele ja mõlemad on väärtuslikud.

Ainult keskmine kuju ütleb, kas rööpsus ühe kliendi sees aitab, mis on tavaliselt transpordi ja tee omadus, mitte serveri oma. Ainult esimene ütleb ülempiiri, mida üks rakendus näeb. Hoidke töökoormus käivituste vahel samana, et võrdlusel oleks mõtet.

Mõõtmine, et numbril oleks mõte

Kirjutage üles serveri ja kliendi versioonid, aktiivne andmetee, läbiräägitud andmesifr, ülekande suund, paketi suurused, voogude arv ja kestus. Jälgige tuuma kohta aktiivsust ning paketi- ja järjekorrakaotusi mõlemas otsas, sest kliendi enda liides, teenusepakkuja võrk või sihtkoha teenus võivad saada piiriks esimesena. Muutke korraga ühte muutujat, sest käivitus, mis muudab sifrit, pakkimist, MTU-d ja mahalaadimist korraga, ei saa teile öelda, milline oli oluline. Hoidke testi ajal seda juurdepääsupoliitikat, mida te tegelikult juurutada kavatsete, sest labori korraldus, mida keegi ei käita, tõestab vähe.

Jätke seejärel varu juhtkanali jaoks, uuesti läbirääkimise jaoks ja kõige muu jaoks, mis hostis töötab.

Teatage, mida konfiguratsioon kavandatud rööpsuse all vastu pidas, mitte määra, mis on ekstrapoleeritud kellegi teise riistvarast. Number koos oma testitingimustega on kasulik; lubadus ilma nendeta on oletus, mida teile hiljem tsitaadina tagasi tuuakse.