OpenVPN ને કેટલા કોર જોઈએ? તે માર્ગ પર આધાર રાખે છે

સમાન પ્રોસેસર સંખ્યાવાળા બે સર્વર ખૂબ જ અલગ થ્રુપુટ ટકાવી શકે છે, કારણ કે મહત્ત્વની સંખ્યા એ છે કે સક્રિય ડેટા માર્ગ ખરેખર કેટલા કોર વાપરી શકે છે। એક ક્લાયન્ટના પેકેટ પ્રોસેસ કરતું એક વપરાશકર્તા-જગ્યાનું ડીમન એક કોર સુધી મર્યાદિત છે, જ્યારે ઓફલોડ કરેલો કર્નલ માર્ગ તે કામ ફેલાવી શકે છે। આમાંથી કોઈ પણ વિધાન એ નથી કહેતું કે આપેલ મશીન તમારા ટ્રાફિક માટે શું કરશે, તેથી કોર ગણતરી પહેલાં માપન આવે છે।

નીચેની સરખામણી એ વિશે છે કે પેકેટ ક્યાં પ્રોસેસ થાય છે, એ વિશે નહીં કે કયું ઉત્પાદન અમૂર્ત રીતે ઝડપી છે। આ અલગ પ્રશ્નો છે અને તેના જવાબ પણ અલગ છે।

વપરાશકર્તા-જગ્યાના માર્ગ પર પ્રતિ પ્રવાહ એક કોર

પરંપરાગત Community OpenVPN ઇન્સ્ટન્સમાં ડેટા ચેનલ વપરાશકર્તા-જગ્યામાં પ્રોસેસ થાય છે, અને વ્યસ્ત કનેક્શન એક પ્રોસેસર પકડી રાખી શકે છે જ્યારે મશીનનો એકંદર ઉપયોગ નજરે ન પડે। એટલે જ એક પ્રવાહ પર પહેલેથી સંતૃપ્ત હોસ્ટમાં કોર ઉમેરવાથી કંઈ બદલાતું નથી: શેડ્યુલર પાસે તે કામ વહેંચવાનો કોઈ રસ્તો નથી। પ્રતિ-ક્લાયન્ટ માળખું એક ક્લાયન્ટના સ્થાનાંતરણને એક કોરની ક્ષમતા સુધી બાંધે છે, કુલ કોર સંખ્યા ગમે તે હોય। પરીક્ષણ દરમિયાન એકંદર આંકડાને બદલે પ્રતિ-કોર ઉપયોગ વાંચો, નહીંતર અડચણ વધારાની ક્ષમતા જેવી લાગશે।

એક હોસ્ટ પર ઘણા સર્વર ઇન્સ્ટન્સ ચલાવવાથી અલગ ક્લાયન્ટ પ્રોસેસમાં વહેંચાય છે। તે હાલના કનેક્શનને સમાંતર કરતું નથી, અને અલગ પૂલ, શ્રોતા અને રાઉટિંગ નિર્ણયોનો ખર્ચ કરે છે।

બીજો માર્ગ: કર્નલમાં પેકેટ

ડેટા ચેનલ ઓફલોડ સમર્થિત પેકેટ પ્રોસેસિંગ અને ક્રિપ્ટોગ્રાફીને કર્નલમાં ખસેડે છે, જ્યાં કામ ઘણા કોર વાપરી શકે છે। તે ક્ષમતાનો પ્રશ્ન એક કોરમાંથી મશીન સુધી બદલે છે, પરંતુ ફક્ત એવી રૂપરેખાઓ માટે જે અમલવારી ટેકો આપે છે: સુસંગત કર્નલ મોડ્યુલ, યોગ્ય ડેટા સાઇફર અને ઓફલોડ જે સુવિધાઓને બાકાત રાખે છે તે વિનાની રૂપરેખા। મોડ્યુલ ઇન્સ્ટોલ કરવું તેનો ઉપયોગ કરવા જેટલું નથી, તેથી કનેક્શનના પોતાના લોગ અથવા સ્ટેટસ આઉટપુટમાંથી સક્રિય મોડની પુષ્ટિ કરો। આવૃત્તિ બેનર સાબિત કરે છે કે શું ઉપલબ્ધ છે, શું ચાલી રહ્યું છે તે નહીં।

ઓફલોડ પ્રમાણીકરણ કે નિયંત્રણ ચેનલ દૂર કરતું નથી, અને દરેક ડિપ્લોયમેન્ટને બહુ-કોર બનાવતું નથી। તે સુસંગત ડેટા માર્ગનું સ્થાનિક પ્રવેગક છે, અને આવશ્યકતાઓ પ્લેટફોર્મ તથા આવૃત્તિ પ્રમાણે બદલાય છે।

સરખામણી ખરેખર શું નક્કી કરે છે

સાચી પસંદગી એ છે કે પ્રતિ-પ્રવાહ મર્યાદા સ્વીકારવી, ક્લાયન્ટને ઇન્સ્ટન્સ વચ્ચે ફેલાવવા, કે સમર્થિત ઓફલોડ રૂપરેખા તરફ જવું। દરેક અલગ સમસ્યા ઉકેલે છે, અને ખોટી પસંદગી આંકડો ખસેડ્યા વિના પૈસા ખર્ચે છે। મહત્ત્વનું પરીક્ષણ એ છે જે સેવાના ઉપયોગની રીત જેવું ઘડાયેલું હોય।

ત્રણ આકાર માપો: એક સ્થાનાંતરણ સાથે એક ક્લાયન્ટ, ઘણા પ્રવાહો સાથે એક ક્લાયન્ટ, અને સાથે ઘણા ક્લાયન્ટ। ત્રીજામાં ઊંચો સરવાળો એ સાબિત કરતો નથી કે એક ડાઉનલોડ ત્યાં પહોંચી શકે, અને ધીમું એકલ સ્થાનાંતરણ એ સાબિત કરતું નથી કે સર્વરની એકંદર ક્ષમતા ખતમ થઈ ગઈ છે। પરિણામો અલગ પ્રશ્નોના જવાબ આપે છે અને બંને રાખવા યોગ્ય છે।

ફક્ત વચ્ચેનો આકાર જ કહે છે કે એક ક્લાયન્ટની અંદરની સમવર્તિતા મદદ કરે છે કે નહીં, જે સામાન્ય રીતે સર્વરની નહીં પણ પરિવહન અને માર્ગની લાક્ષણિકતા છે। ફક્ત પહેલો જ એ મર્યાદા કહે છે જે એક એપ્લિકેશન જોશે। સરખામણી અર્થપૂર્ણ થાય તે માટે રન વચ્ચે કામભાર સમાન રાખો।

માપો જેથી આંકડાનો અર્થ રહે

સર્વર અને ક્લાયન્ટની આવૃત્તિઓ, સક્રિય ડેટા માર્ગ, વાટાઘાટ થયેલો ડેટા સાઇફર, સ્થાનાંતરણની દિશા, પેકેટના આકાર, પ્રવાહની સંખ્યા અને અવધિ નોંધો। પ્રતિ-કોર પ્રવૃત્તિ અને બંને છેડે પેકેટ તથા કતાર ડ્રોપ જુઓ, કારણ કે ક્લાયન્ટનું પોતાનું ઇન્ટરફેસ, પ્રદાતાનું નેટવર્ક કે ગંતવ્ય સેવા પહેલાં મર્યાદા બની શકે છે। એક સમયે એક ચલ બદલો, કારણ કે સાઇફર, સંકોચન, MTU અને ઓફલોડ સાથે બદલતો રન કહી શકતો નથી કે કયો મહત્ત્વનો હતો। પરીક્ષણ દરમિયાન તમે ખરેખર જે પ્રવેશ નીતિ લાગુ કરવા માંગો છો તે રાખો, કારણ કે કોઈ ન ચલાવે એવી પ્રયોગશાળા ગોઠવણ થોડું જ સાબિત કરે છે।

પછી નિયંત્રણ ચેનલ માટે, ફરી વાટાઘાટ માટે અને હોસ્ટ પર ચાલતા બાકીના બધા માટે જગ્યા છોડો।

ઇચ્છિત સમવર્તિતા હેઠળ રૂપરેખાએ શું ટકાવ્યું તે જણાવો, બીજાના હાર્ડવેરથી અંદાજેલા દરને બદલે। પરીક્ષણની શરતો સાથેનો આંકડો ઉપયોગી છે; તેમના વિનાનું વચન એવી ધારણા છે જે તમને પાછળથી ટાંકવામાં આવશે।