VPN ડાઉનલોડ સર્વરના અપલોડ દ્વારા કેમ મર્યાદિત થાય છે

ક્લાયન્ટ ઝડપી ડાઉનલિંક દેખાડે છે, સર્વર ફાઇબર કનેક્શન પર બેઠું છે, અને છતાં ટ્રાન્સફર ધીમે ધીમે ચાલે છે. લોકો જે સંખ્યા સરખાવે છે તે સામાન્ય રીતે ક્લાયન્ટના પ્લાન પર છપાયેલી સંખ્યા હોય છે, જ્યારે પેકેટ ખરેખર પહેલાં સર્વરની આઉટબાઉન્ડ એક્સેસ લિંક પાર કરે છે. એ લિંક એ બજેટ છે જેમાં ટ્રાન્સફરને બંધ બેસવું પડે. નાના ઘરના કનેક્શન પર એ પથની સૌથી નાની સંખ્યા છે.

તમે વાંચેલી સંખ્યા ખોટી દિશામાં હતી

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

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

પથને બજેટ તરીકે લખો

પેકેટે પાર કરવાની હોય તેવી દરેક સીમા યાદીમાં લખો અને દરેકને એ જ એકમમાં સંખ્યા આપો. સ્રોત તરફથી ડિલિવરી, સર્વર પર પ્રોસેસિંગ, સર્વરની અપલિંક, વચ્ચેનો પથ, ક્લાયન્ટની ડાઉનલિંક અને ક્લાયન્ટ પર પ્રોસેસિંગ — બધા લાગુ પડે છે. વાપરી શકાય તેવો દર એમાંથી સૌથી નાનો છે, ઓવરહેડ બાદ કરીને, અને એ ટોચમર્યાદાની ઉપરનું કોઈ ટ્યુનિંગ પરિણામ બદલતું નથી. માપતા પહેલાં યાદી લખી રાખો, કારણ કે એ કહે છે કે કઈ સંખ્યા પર ભરોસો ન કરવો.

સર્વરની 20 Mbit/s અપલિંક અને ક્લાયન્ટની 100 Mbit/s ડાઉનલિંક સાથે, સર્વર ક્લાયન્ટને ધ્યાનમાં આવે તે પહેલાં ઘણું વહેલું ટ્રાન્સફર મર્યાદિત કરે છે. ઓવરહેડ અને કોઈપણ સાથોસાથ ટ્રાન્સફર વધુ એક ભાગ લે છે, અને સંતૃપ્ત અપલિંક પુષ્ટિ પણ મોડી કરે છે, જે TCP ટ્રાન્સફરને કાચી ટોચમર્યાદાની નીચે ધીમું કરે છે. બંનેમાંથી કોઈ અસર પ્લાન સરખામણીમાં દેખાતી નથી.

મેગાબિટ અને મેગાબાઇટ અલગ રાખો, અને કહો કે દરેક આંકડો એન્ક્રિપ્ટેડ લિંક ટ્રાફિક માપે છે કે એપ્લિકેશન પેલોડ. આ બંને ભેગા કરવા એ બજેટ ન મળતું દેખાવાનું સૌથી સામાન્ય કારણ છે. દરેક આંકડાને તેના એકમ અને માપન બિંદુ સાથે લેબલ કરો.

બોર્ડ ખરેખર તમને ક્યાં મોંઘું પડે છે

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

એક જ CPU સરેરાશને બદલે અલગ પ્રોસેસિંગ પથ સરખાવો. મધ્યમ એકંદર ભાર એક સંતૃપ્ત કોર છુપાવી શકે છે જે દરેક પેકેટનું બધું કામ કરે છે, અને ક્લોક ફ્રિક્વન્સી પ્રોસેસર ડિઝાઇન વચ્ચે પ્રદર્શન સ્કોર તરીકે પસાર થતી નથી. પેકેટ દર એટલો જ મહત્ત્વનો છે જેટલો થ્રુપુટ, કારણ કે નાના પેકેટ મોટા કરતાં પ્રતિ બાઇટ વધુ મોંઘા પડે છે. તમારો વર્કલોડ ખરેખર જે પેકેટ સાઇઝ વાપરે છે તેનાથી માપો.

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

વેન્ડરની પ્રદર્શન માર્ગદર્શિકા એક્સેસ બેન્ડવિડ્થ, CPU, પેકેટ પ્રોસેસિંગ, ટ્રાન્સપોર્ટ અને પેકેટ સાઇઝને અલગ મર્યાદાઓમાં વિભાજિત કરે છે. સાઇફર બદલતા પહેલાં એ વાંચવા યોગ્ય છે, કારણ કે સાઇફર ફેરફાર ભાગ્યે જ એવી સીમા ખસેડે છે જે કદી મર્યાદા ન હતી.

સાઇફર બદલતા પહેલાં માપો

એક દિશાત્મક પરીક્ષણ ચલાવો જે ટનલમાંથી ખરેખર મળેલો દર જણાવે, પછી સરખામણી માટે એ જ પરીક્ષણ કાચા ઇન્ટરફેસ પર ચલાવો. એ બે સંખ્યા વચ્ચેનો ફરક ટનલનો ખર્ચ છે, અને બે ટોચમર્યાદામાંથી નાની કહે છે કે કઈ સીમા પર હુમલો કરવો.

સરખામણી કરતી વખતે સુરક્ષા નીતિ અકબંધ રાખો. નબળા સાઇફર કે ઓવરક્લોક કરેલા બોર્ડ સાથે મળેલું જૂનું પરિણામ વર્તમાન ડિપ્લોયમેન્ટ માટે યોજના નથી.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

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