GCP સ્થિર IP વિરુદ્ધ VPN ઝડપ: ત્રણ ચલ, એક કસોટી
અનામત સરનામું એ ઝડપનું સેટિંગ નથી। Compute Engine પર થ્રુપુટની સરખામણી કરતા પહેલાં સરનામાનું જીવનચક્ર, નેટવર્ક સ્તર અને OpenVPN પરિવહન અલગ કરો।
સરનામું અનામત થયા પછી સ્થાનાંતરણ ઝડપી બન્યું, અને તારણ જાતે લખાઈ ગયું। ફક્ત એટલું જ કે એ જ ફેરફારે ટનલને UDP થી TCP પર ખસેડ્યું, કસોટીને બીજી સાંજે ખસેડી અને કદાચ બીજા ઝોનની VM પર ઉતર્યું। બાહ્ય સરનામું અનામત કરવું જીવનચક્રની સમસ્યા ઉકેલે છે: તે પુનઃપ્રારંભ દરમિયાન એન્ડપોઇન્ટ સમાન રાખે છે। તેમાં પેકેટને વેગ આપે એવી કોઈ પદ્ધતિ નથી, તેથી તે પ્રયોગમાંનો ઝડપનો તફાવત બીજા ચલોનો છે, અને તમારી સામેનો નિર્ણય એ છે કે આગળ કયું પરીક્ષણ કરવું।
અનામત સરનામું ખરેખર શું ખરીદે છે
Compute Engine ઇન્સ્ટન્સ સાથે ફાળવાયેલા અને મુક્ત થતા અલ્પજીવી સરનામાંઓને તમે અનામત રાખો છો તે સ્થિર સરનામાંઓથી અલગ પાડે છે। એ ફરક જાળવણી અને બિલિંગ વિશે છે, પેકેટ જે માર્ગ લે છે તેના વિશે નહીં। સ્થિર એન્ડપોઇન્ટ DNS રેકોર્ડ, દૂરસ્થ પ્રવેશ પ્રોફાઇલ, ભાગીદાર મંજૂરી-યાદીઓ અને ફાયરવોલ નિયમો માટે ખરેખર ઉપયોગી છે, જે VM ફરી શરૂ થાય ત્યારે બદલાવું ન જોઈએ।
એક અનામત કરવા માટે આ સારા કારણો છે। એમાંનું એક પણ થ્રુપુટનું કારણ નથી।
સ્તર, સરનામું અને પરિવહનને ત્રણ ચલ તરીકે રાખો
Google Cloud Premium અને Standard Network Service Tier પણ વેચે છે, અને બંને અલગ અલગ સુવિધા ઉપલબ્ધતા સાથે ઇન્ટરનેટ તરફ અલગ માર્ગ લે છે। સ્થિર સરનામાંકન બંને માટે ઓર્થોગોનલ છે, તેથી સ્થિર અને Premium ને VM વિશેના અસંબંધિત તથ્યો તરીકે ગણો, સમાનાર્થી તરીકે નહીં। વાસ્તવિક સ્તર, પ્રદેશ અને અમલમાં રહેલું કોઈપણ ઇન્ટરકનેક્શન કે એટેચમેન્ટ નોંધો, કારણ કે તે માર્ગનું એવી રીતે વર્ણન કરે છે જે સરનામાનું લેબલ કદી નહીં કરે।
ત્રણ ચલ, ત્રણ અલગ પ્રયોગો, નહીં તો પરિણામ એક વાર્તા છે, માપ નહીં।
એક પ્રશ્નનો જવાબ આપતી કસોટી ડિઝાઇન કરો
મંજૂર UDP અને TCP પ્રોફાઇલની સરખામણી કરતી વખતે VM, સરનામું, ક્લાઇન્ટનું સ્થાન, લક્ષ્ય અને વર્કલોડ સ્થિર રાખો। દરેક પરિવહન માટે સર્વર શ્રોતા અને મેળ ખાતા ફાયરવોલ નિયમો—બંને જરૂરી છે; ક્લાઇન્ટમાં કીવર્ડ બદલીને શ્રોતાને અપરિવર્તિત રાખવાથી ફક્ત તમારી ધીરજનું પરીક્ષણ થાય છે। પુનરાવર્તનીય સ્થાનાંતરણ વાપરો અને દિશા, અવધિ, એક અને સમાંતર સ્ટ્રીમ તથા એકમો નોંધો, કારણ કે MB/s અને Mb/s આઠ ગણા અલગ છે।
VM ના CPU પર પણ નજર રાખો, કારણ કે નાનું ઇન્સ્ટન્સ એન્ક્રિપ્શન કે softirq કામમાં નેટવર્ક પહેલાં ઘણું વહેલું સંતૃપ્ત થાય છે, અને એ મર્યાદા બરાબર પ્રદાતાની મર્યાદા જેવી દેખાશે।
VM અને ક્લાઇન્ટના પુનઃપ્રેષણ અને નુકસાન કાઉન્ટર માર્ગની સમસ્યાને પરિવહનની સમસ્યાથી અલગ પાડે છે, અને પ્રગતિ પટ્ટી એ કરી શકતી નથી। iperf3 સાથેનો કાર્યક્ષમ ક્રમ દરેક પરિવહન માટે લગભગ દસ મિનિટ લે છે। દૂરના છેડે સર્વર શરૂ કરો, દરેક દિશામાં ત્રીસ સેકન્ડ ક્લાઇન્ટ ચલાવો અને દરેક દિશા ત્રણ વાર પુનરાવર્તિત કરો। દરેક શ્રેણીની પ્રથમ રન કાઢી નાખો, પછી TCP રન જે પુનઃપ્રેષણ સંખ્યા છાપે છે તેની સાથે મોકલનાર અને પ્રાપ્તકર્તાના દરની સરખામણી કરો।
UDP અને TCP યાંત્રિક રીતે કેમ અલગ છે
UDP પર OpenVPN ડેટાગ્રામ વહન કરે છે અને નુકસાન સંભાળવાનું એપ્લિકેશનના પોતાના પરિવહનને સોંપે છે। TCP પર ટનલનો વિશ્વસનીય પ્રવાહ પહેલેથી વિશ્વસનીય એપ્લિકેશન પ્રવાહની નીચે બેસે છે, તેથી એક ખોવાયેલ સેગમેન્ટ તેની પાછળનું બધું અટકાવે છે જ્યારે બાહ્ય જોડાણ પોતાના સમયપત્રક મુજબ પુનઃપ્રેષણ કરે છે। આ હેડ-ઓફ-લાઇન વર્તન TCP ને TCP ની અંદર ટનલ કરવાની લાક્ષણિકતા છે, પ્રદાતાની નીતિ નહીં। MTU અને MSS ની સંભાળ પણ બે મોડ વચ્ચે અલગ છે, જે એ જ માર્ગ પર ફ્રેગમેન્ટેશન વર્તન બદલે છે।
તેથી ઝડપી TCP કસોટી ફક્ત એ સાબિત કરે છે કે તે દિવસે તે માર્ગ પર TCP ઝડપી હતું, અને વધુ સામાન્ય કંઈ નહીં।
પરિણામ એવી રીતે લખો કે તે સમીક્ષામાં ટકી રહે
સમર્થનીય તારણનું એક સ્વરૂપ હોય છે: આ પ્રોફાઇલ, આ મશીન કદ પર, આ નેટવર્ક સ્તર પર, આ માપેલો વર્કલોડ આ દિશામાં આ પરિસ્થિતિઓ હેઠળ ટકાવી રાખ્યો। આનાથી વધુ વ્યાપક કંઈપણ એક સાંજ આપી શકે તેના કરતાં વધુ રન માગે છે। જો ધીમો કિસ્સો અસ્પષ્ટ રહે, તો કોઈ પ્રદાતા દસ્તાવેજ વર્ણવતું ન હોય એવું થ્રોટલ શોધવાને બદલે પેકેટ અને સંસાધન પુરાવા સાથે તેને અવલોકન તરીકે રાખો।
સરનામાની સ્થિરતા અને સ્થાનાંતરણ ઝડપ એક જ ડિપ્લોયમેન્ટ માટે બંને મહત્વપૂર્ણ હોઈ શકે, અને ઉપયોગી નિર્ણય એ છે કે દરેક ફેરફાર સાથે તમે કયું ખરીદો છો।