Går ruteren eller den bærbare tom for CPU? Derfor stopper VPN-farten for tidlig
En ruter eller bærbar kan gå tom for regnekraft før forbindelsen fylles. Overvåk belastningen per kjerne under en kontrollert overføring, og sjekk deretter offload før du gir noen skylden.
En ruter reklamerer med raskt Wi-Fi og sliter deretter med å kryptere trafikken til tre enheter samtidig. En bærbar når en grense for regnekraft mens adgangslinjen fortsatt har plass. Serveren får vanligvis skylden først, og den er vanligvis uskyldig. Grensen sitter på maskinen som gjør tunnelarbeidet, og å finne den betyr å overvåke den maskinen i stedet for fartstesten.
Symptomet peker på én maskin, ikke på internettet
Hvor tunnelen kjører avgjør hvilken prosessor som betaler for den. Hvis ruteren avslutter den, deler hver dekket klient den ruterens budsjett. Hvis den bærbare kjører en klient, betaler den bærbare og ikke ruteren. Tunneler i begge ender skaper to arbeidsbelastninger som hver kan bli grensen en annen dag. Å navngi maskinen er det første trinnet, og det er trinnet folk hopper over når de åpner en sak mot leverandøren.
Tell enhetene mellom applikasjonen og den fjerne enden, og merk deretter den som krypterer. Alt annet er bare en bærer av byte den ikke kan lese.
Overvåk belastningen per kjerne under en overføring
En samlet CPU-prosent er feil instrument, fordi krypteringsarbeid ofte binder én enkelt kjerne mens resten står ledig. Se på tall per kjerne under en kontrollert overføring og følg med på en kjerne nær metning. Et moderat gjennomsnitt med én travel tråd er et sterkt signal, mens et høyt gjennomsnitt uten en travel tråd vanligvis betyr et urelatert program. Mønsteret betyr mer enn tallet.
mpstat -P ALL 1 5
top -H -b -n 1 | head -20
lscpu | grep -i -E "model name|aes"
Den tredje kommandoen forteller om prosessoren tilbyr AES-instruksjoner, noe som endrer kostnaden for samme chiffer i stor grad. Den forteller ikke om VPN-implementasjonen bruker dem, og nettopp gapet mellom disse to fakta er der de fleste optimaliseringspåstander kommer fra.
Skill kryptering fra pakkehåndtering
Kryptering er én kostnad blant flere. Kopiering av pakker mellom kjernen og brukerområdet, ruteoppslag, brannmurregler og grensesnittbehandling bidrar alle, og noen implementasjoner betaler mer for kopiering enn for kryptografi. Legg merke til hvilken teller som stiger sammen med overføringen i stedet for å stole på at prosessnavnet forklarer hver syklus. En tunnel i brukerområdet og en tunnel i kjernen kan vise helt forskjellige profiler for identisk trafikk.
Hvis én kjerne er travel inne i kjernen, er botemiddelet annerledes enn en travel tråd i brukerområdet, og profilen forteller deg hvilken du har. Den forskjellen er verdt en time før du kjøper maskinvare.
Sammenlign likt med likt før du konkluderer
En sammenligning er bare nyttig hvis oppgaven, aksessnettet og endepunktet forblir de samme. Bytt server, og resultatet inkluderer den serverens rute og kapasitet; bytt nett, og det inkluderer operatøren. Bruk samme fil, samme destinasjon og samme tid på dagen, og stopp ditt eget bakgrunnsarbeid. Hvis du må bytte enhet, bytt bare enheten.
Strøm og varme endrer vedvarende ytelse, så en kort kjøring på en kald maskin er ikke samme måling som en lang overføring på en varm. Sammenlign like strømforhold og skriv dem ned, fordi en termisk grense ser nøyaktig ut som en regnekraftgrense i en graf.
Bruk støttet offload og verifiser at det faktisk ble aktivert
Noen implementasjoner kan flytte deler av datastien inn i kjernen eller ut i maskinvaren, og tilgjengeligheten avhenger av klienten, operativsystemet, serveren og konfigurasjonen. Les dokumentasjonen for versjonen du kjører og bruk dens egen statusutskrift eller logger for å bekrefte at funksjonen er aktiv. En installert pakke eller et avkrysset felt er ikke bevis. OpenVPN-håndboken dokumenterer datakanalvalg for sine egne utgivelser, og disse valgene er forskjellige mellom versjoner.
Når en støttet endring flytter taket, kjør både applikasjonsoppgaven og en bulkoverføring på nytt, og behold den forrige profilen slik at du kan rulle tilbake. En bulkrate som dobles mens applikasjonen forblir treg har flyttet flaskehalsen i stedet for å fjerne den.
Hvis prosessorobservasjonene ikke følger symptomet, gå tilbake til nettverkssiden. Wi-Fi-forsøk på nytt, køing og utgangsstien gir samme resultat helt uten CPU-innblanding.