VPN પર ફાઇલ શેરિંગ ધીમું કેમ લાગે: રાઉન્ડ ટ્રિપ્સ, Mbps નહીં

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

દૂરની કાર્યકારી નકલનો આકાર ખોટો છે

SMB ફાઇલો ખોલે છે, મેટાડેટા વાંચે છે અને ઘણા નાના આદાનપ્રદાનમાં પુષ્ટિ આપે છે. મેપ કરેલી ડ્રાઇવ પરની વર્ઝન-કંટ્રોલ કાર્યકારી નકલ સ્થાનિક ફાઇલસિસ્ટમ વિલંબ ધારી લે છે અને ઘણી નાની ફાઇલો વાંચે છે. ડેસ્કટોપ ડેટાબેઝ વપરાશકર્તા કામ કરે ત્યારે પૃષ્ઠો ખેંચે છે. આમાંથી દરેક વિલંબને ગુણક બનાવે છે, કારણ કે ખર્ચ એ કામગીરી કેટલા આદાનપ્રદાન કરે છે તેની સાથે વધે છે; તેથી 40 msનું ટનલ થોડા સો કામગીરીને થોડી સેકન્ડમાં ફેરવે છે. તે ગણિતમાં પેલોડનું કદ લગભગ અપ્રસ્તુત છે.

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

મેગાબાઇટ પહેલાં રાઉન્ડ ટ્રિપ્સ ગણો

ક્ષમતા ખરીદતા પહેલાં વિલંબ માપો. એક ping કહે છે કે દરેક આદાનપ્રદાન શું ચૂકવે છે.

ping -c 10 fileserver.example.net

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

કામ ખસેડો, બાઇટ્સ નહીં

વધુ પાઇપ માટે ચૂકવવાને બદલે કામ ક્યાં થાય છે તે બદલો. રિપોઝિટરીને માઉન્ટ કરવાને બદલે સેવા આપો, અને ફક્ત તફાવત મોકલતા સાધન સાથે સામૂહિક રીતે નકલ કરો.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

રિપોઝિટરીની સેવા આપવી, જેમ hgweb કે દૂરનું Git કરે છે, ક્લાઇન્ટને સ્થાનિક ક્લોન પર કામ કરવા દે છે જેથી તેની ફાઇલસિસ્ટમ કૉલ કદી ટનલ પાર ન કરે. rsync બંને બાજુ ચાલે છે અને બદલાયેલા બ્લોક મોકલે છે, જે સાદી નકલ ચૂકવે છે તે મોટા ભાગના આદાનપ્રદાન દૂર કરે છે. ડેસ્કટોપ ડેટાબેઝ સર્વર-સાઇડ એન્જિન પરનો હોય અને ક્લાઇન્ટ ફક્ત આગળનું ઇન્ટરફેસ રહે, અથવા આખો ક્લાઇન્ટ આંતરિક હોસ્ટ પર ચાલે. દરેક વિકલ્પ બદલે છે કે પ્રોટોકોલ કેટલા વિલંબ સામે છે, અને એ જ મુદ્દો છે.

એક જ કદ પાસે અટકી જવું MTUનું લક્ષણ છે

મોટા ટ્રાન્સફર લગભગ સમાન ડેટા પછી અટકી જાય, જ્યારે ping અને નાના પૃષ્ઠ કામ કરે, તે બેન્ડવિડ્થને બદલે પેકેટના કદ તરફ ઇશારો કરે છે.

ping -M do -s 1400 -c 3 fileserver.example.net

સફળ પ્રોબનો અર્થ છે કે 1428 બાઇટનું IP પેકેટ ટુકડા વગર પથ પાર કરે છે, કારણ કે ICMP અને IP હેડર 28 બાઇટ ઉમેરે છે. ટુકડા ન કરવાના ફ્લેગ સાથે નિષ્ફળતા સૂચવે છે કે ટનલનું વપરાયોગ્ય MTU સર્વર ધારે છે તેના કરતાં નાનું છે. જે સર્વર 9000 બાઇટના બફર 1500 બાઇટના પથ પર મોકલે છે તે ટુકડા અથવા ડ્રોપ ફરજિયાત કરે છે, અને ICMP ફિલ્ટર થાય ત્યારે પથ MTUની શોધ શાંતિથી નિષ્ફળ જઈ શકે છે. ટનલનું MTU ઘટાડો, સક્રિય કરો mssfix OpenVPN પર, અથવા સર્વરના બફર નાના કરો, પછી પુષ્ટિ માટે એ જ ટ્રાન્સફર ફરી ચલાવો.

જે અંતર મહત્વનું છે તે માપો

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

જ્યારે ફક્ત શરૂઆતના મેગાબાઇટ ખેંચાય, ત્યારે પ્રમાણીકરણ અને મેટાડેટા જુઓ; જ્યારે બધું ધીમું ચાલે, ત્યારે ક્ષમતા અને નુકસાન જુઓ. મેળ ખાતું કારણ સુધારો, અને WAN લિંક LAN કેબલની જેમ વર્તશે એવી અપેક્ષા છોડો.