Ilang Core ang Kailangan ng OpenVPN? Depende ito sa Landas

Dalawang server na may parehong bilang ng processor ay maaaring mapanatili ang magkaibang throughput, dahil ang bilang na mahalaga ay kung ilang core ang aktwal na magagamit ng aktibong landas ng datos. Ang isang daemon sa espasyo ng gumagamit na nagpoproseso ng mga packet ng isang kliyente ay limitado sa isang core, samantalang ang isang landas sa kernel na naka-offload ay maaaring magpakalat ng gawaing iyon. Wala sa dalawang pahayag ang nagsasabi kung ano ang gagawin ng isang partikular na makina sa iyong trapiko, kaya ang pagsukat ay nauuna sa pagbilang ng mga core.

Ang paghahambing sa ibaba ay tungkol sa kung saan pinoproseso ang mga packet, hindi tungkol sa kung aling produkto ang mas mabilis sa abstraktong paraan. Magkaibang tanong ang mga ito na may magkaibang sagot.

Isang core bawat daloy sa landas sa espasyo ng gumagamit

Sa isang tradisyonal na Community OpenVPN instance, ang channel ng datos ay pinoproseso sa espasyo ng gumagamit, at ang abalang koneksyon ay maaaring humawak ng isang processor habang ang kabuuang paggamit ng makina ay nananatiling hindi kapansin-pansin. Kaya ang pagdagdag ng mga core sa isang host na puspos na sa isang daloy ay walang binabago: walang paraan ang scheduler na hatiin ang gawaing iyon. Ang istrukturang isang proseso bawat kliyente ay naglilimita sa paglipat ng isang kliyente sa kapasidad ng isang core, gaano man karami ang kabuuang bilang ng core. Basahin ang paggamit bawat core sa panahon ng pagsubok sa halip na ang kabuuang bilang, kung hindi ay magmumukhang libreng espasyo ang bottleneck.

Ang pagpapatakbo ng ilang instance ng server sa isang host ay naghahati ng magkahiwalay na kliyente sa mga proseso. Hindi nito pinaparis ang isang umiiral na koneksyon, at nagkakahalaga ito ng magkahiwalay na pool, listener at desisyon sa pagruruta.

Ang isa pang landas: mga packet sa kernel

Offload ng channel ng datos inililipat ang sinusuportahang pagpoproseso ng packet at kriptograpiya sa kernel, kung saan magagamit ng trabaho ang ilang core. Binabago nito ang tanong ng kapasidad mula sa isang core patungo sa makina, ngunit para lamang sa mga konfigurasyong sinusuportahan ng implementasyon: isang katugmang module ng kernel, isang karapat-dapat na cipher ng datos at isang konfigurasyong walang mga feature na ibinubukod ng offload. Ang pag-install ng module ay hindi katulad ng paggamit nito, kaya tiyakin ang aktibong mode mula sa log ng koneksyon mismo o sa output ng status. Ang banner ng bersyon ay nagpapatunay kung ano ang available, hindi kung ano ang tumatakbo.

Hindi inaalis ng offload ang pagpapatunay o ang control channel, at hindi nito ginagawang multi-core ang bawat deployment. Ito ay lokal na pagpapabilis ng isang katugmang landas ng datos, at nagkakaiba ang mga pangangailangan ayon sa platform at bersyon.

Ano ang talagang pinagpapasyahan ng paghahambing

Ang tunay na pagpipilian ay nasa pagitan ng pagtanggap ng kisame bawat daloy, paghahati ng mga kliyente sa mga instance, at paglipat sa isang sinusuportahang konfigurasyon ng offload. Ang bawat isa ay tumutugon sa magkaibang problema, at ang pagpili ng mali ay gumagastos ng pera nang hindi ginagalaw ang bilang. Ang pagsubok na mahalaga ay ang hugis ng paraan ng paggamit ng serbisyo.

Sukatin ang tatlong hugis: isang kliyente na may isang paglipat, isang kliyente na may ilang daloy, at ilang kliyente nang sabay. Ang mataas na kabuuan sa pangatlo ay hindi nagpapatunay na kayang maabot iyon ng isang pag-download, at ang mabagal na isang paglipat ay hindi nagpapatunay na naubos na ng server ang kabuuang kapasidad nito. Magkaibang tanong ang sinasagot ng mga resulta at kapwa sulit panatilihin.

Ang gitnang hugis lamang ang nagsasabi kung nakakatulong ang sabayang pagganap sa loob ng isang kliyente, na kadalasan ay katangian ng transportasyon at landas at hindi ng server. Ang una lamang ang nagsasabi ng kisame na makikita ng isang aplikasyon. Panatilihing pareho ang karga ng trabaho sa pagitan ng mga pagtakbo upang may kahulugan ang paghahambing.

Pagsukat upang may kahulugan ang bilang

Itala ang mga bersyon ng server at kliyente, ang aktibong landas ng datos, ang napagkasunduang cipher ng datos, ang direksyon ng paglipat, ang mga laki ng packet, ang bilang ng daloy at ang tagal. Bantayan ang aktibidad bawat core at ang pagkawala ng packet at pila sa magkabilang dulo, dahil ang interface ng kliyente mismo, ang network ng provider o ang destinasyong serbisyo ay maaaring maging limitasyon muna. Baguhin ang isang variable sa isang pagkakataon, dahil ang pagtakbo na nagbabago ng cipher, compression, MTU at offload nang sabay ay hindi masasabi kung alin ang mahalaga. Panatilihin ang patakaran sa pag-access na talagang balak mong ilunsad sa panahon ng pagsubok, dahil ang kaayusan sa laboratoryo na walang magpapatakbo ay kakaunti ang pinatutunayan.

Pagkatapos ay mag-iwan ng espasyo para sa control channel, para sa muling pag-uusap at para sa lahat ng iba pang tumatakbo sa host.

Iulat kung ano ang napanatili ng konfigurasyon sa ilalim ng inilaan na sabayang pagganap, sa halip na isang rate na hinango mula sa hardware ng iba. Ang bilang na may kalakip na mga kondisyon ng pagsubok ay kapaki-pakinabang; ang pangakong wala ang mga iyon ay isang haka-haka na babanggitin pabalik sa iyo.