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 కేబుల్ లాగా ప్రవర్తిస్తుందని ఆశించడం మానేయండి.