పెద్ద అప్లోడ్ల సమయంలో VPN కట్ అవుతుంది: మొదట క్యూను చదవండి
నిండిన అప్స్ట్రీమ్ క్యూ నియంత్రణ ట్రాఫిక్ను కూడా అప్లికేషన్ల మాదిరిగానే ఆలస్యం చేస్తుంది. నిష్క్రియ మరియు భారం ఉన్న స్థితిలో ప్రవర్తనను పోల్చి చూడండి, తరువాత ఒక విషయాన్ని మార్చి పరీక్షను పునరావృతం చేయండి.
టన్నెల్ రోజంతా స్థిరంగా ఉంటుంది, ఆపై పెద్ద అప్లోడ్ ప్రారంభమైన ప్రతిసారీ కట్ అవుతుంది. ఇంటరాక్టివ్ అభ్యర్థనలు మొదట ఆగిపోతాయి, క్లయింట్ సమయం ముగిసినట్లు నివేదిస్తుంది, బదిలీ ముగిసినప్పుడు కనెక్షన్ తిరిగి వస్తుంది. ఈ నమూనా రిమోట్ సర్వర్ పడిపోవడం కాకుండా క్యూ మరియు ప్రాసెసింగ్ను సూచిస్తుంది, ఎందుకంటే సర్వర్కు సమయానికి సమాధానం ఇచ్చే అవకాశం ఎప్పుడూ ఇవ్వబడలేదు. పని ఏమిటంటే నియంత్రిత భారం క్రింద దీన్ని పునఃసృష్టించి సరైన కౌంటర్లను చదవడం.
ప్రతి పరుగుకు ఒక వేరియబుల్ మార్చండి మరియు ముగింపు బిందువును స్థిరంగా ఉంచండి.
పునరావృతమయ్యే భార పోలికను నిర్మించండి
లింక్ నిష్క్రియంగా ఉన్నప్పుడు ఆధార రేఖను నమోదు చేయండి: వెళ్లి రావడం సమయం, కొన్ని అప్లికేషన్ అభ్యర్థనలు మరియు టన్నెల్ సొంత ఈవెంట్ లాగ్. తరువాత తెలిసిన పరిమాణంతో అప్లోడ్ ప్రారంభించి అది నడుస్తున్నప్పుడు అదే కొలతలను సరిగ్గా పునరావృతం చేయండి. ముగింపు బిందువు, క్లయింట్ మరియు పరీక్ష గమ్యాన్ని మార్చకుండా ఉంచండి, ఎందుకంటే వాటిలో రెండింటిని ఒకేసారి మార్చడం మీకు ఏమీ చెప్పదు.
ఏ ఈవెంట్ మొదట కనిపిస్తుందో గమనించండి. ఏదైనా లోపానికి ముందు పెరుగుతున్న వెళ్లి రావడం సమయం క్యూను సూచిస్తుంది; స్థిరమైన ఆలస్యంతో కఠినమైన సమయ ముగింపు మరొకదాన్ని సూచిస్తుంది, ఉదాహరణకు కీ మార్పు లేదా ఖాతాపై చర్య. రెండు నమూనాలు వేర్వేరు తదుపరి దశలకు దారితీస్తాయి. ఏదైనా మార్చే ముందు పరిశీలనను రాయండి.
అవుట్పుట్ను సమయ ముద్రలతో సేవ్ చేయండి, అప్పుడు భారం ఉన్న మరియు నిష్క్రియ పరుగులను పంక్తి పంక్తిగా పోల్చవచ్చు.
వేగం కాదు, క్యూ చదవండి
వినియోగదారు లింక్లు ప్రదాత పరికరాలలో ప్యాకెట్లను బఫర్ చేస్తాయి, నిండిన అప్స్ట్రీమ్ క్యూ టన్నెల్ను సజీవంగా ఉంచే చిన్న నియంత్రణ ప్యాకెట్లతో సహా అన్నింటినీ ఆలస్యం చేస్తుంది. అధిక సంఖ్యను నివేదించే వేగ పరీక్ష ఆ ఆలస్యం గురించి కొంచెమే చెబుతుంది, అందుకే నిష్క్రియ లింక్లో పరీక్ష ఉత్తీర్ణమవుతుంది కానీ నిండిన లింక్ విఫలమవుతుంది.
ping -c 20 -i 0.2 203.0.113.10 mtr -rwc 20 203.0.113.10 tc -s qdisc show dev eth0 ss -ti dst 203.0.113.10 nstat -az | grep -E 'Retrans|Timeout'
భారం ఉన్న ఆలస్య సంఖ్యలను నిష్క్రియ వాటితో పోల్చండి. ప్యాకెట్ నష్టం లేకుండా పదుల మిల్లీసెకన్ల నుండి వందలకు దూకడం క్యూ; స్థిరమైన ఆలస్యంతో నష్టం మరొక లోపాన్ని సూచిస్తుంది.
పరికరం మరియు నియంత్రణ మార్గాన్ని తనిఖీ చేయండి
ఎన్క్రిప్షన్ మరియు ఫార్వార్డింగ్ ప్రాసెసర్ సమయాన్ని తీసుకుంటాయి, చిన్న రౌటర్ లేదా వేడితో పరిమితమైన ల్యాప్టాప్ బిజీగా ఉన్నప్పుడు ప్యాకెట్లను వదిలేయవచ్చు. ఒక ప్రాసెస్ శాతం కాదు, మొత్తం భారాన్ని గమనించండి, ఎందుకంటే కెర్నల్ ఫార్వార్డింగ్ మరియు ఇంటరప్ట్ నిర్వహణ ప్రజలు సాధారణంగా చూసే చోట కనిపించవు.
uptime mpstat -P ALL 1 3 dmesg | grep -i -E 'thermal|throttl' journalctl -u openvpn-server@server --since '10 min ago' | tail -20
క్లయింట్ సమయ ముగింపు షెడ్యూల్ చేసిన కీ మార్పు లేదా సెషన్ విధాన ఈవెంట్తో కూడా కలిసి రావచ్చు. ఈవెంట్ల క్రమం కోసం అప్లికేషన్ లోప సందేశం మాత్రమే కాదు, క్లయింట్ సొంత లాగ్ను చదవండి.
ఒక విషయాన్ని మార్చి పునరావృతం చేయండి
వేదిక మద్దతు ఉన్న చోట, అప్లోడ్ రేటును పరిమితం చేయండి లేదా బల్క్ ట్రాఫిక్ను ఇంటరాక్టివ్ ట్రాఫిక్ క్రింద వర్గీకరించండి, క్యూ ఎప్పుడూ నిండకుండా. తరువాత అదే పని భారాన్ని పునరావృతం చేసి మునుపటిలాగే అదే మూడు సంఖ్యలను పోల్చండి. వేగ పరీక్షను మెరుగుపరిచినా సమయ ముగింపును అలాగే ఉంచే మార్పు ఏమీ సరిచేయలేదు.
అన్ని చోట్లా సమయ పరిమితులను పెంచడం మరియు ఎన్క్రిప్షన్ను బలహీనపరచడం ఏ సీమ విఫలమైందో గుర్తించకుండా లక్షణాన్ని మాయం చేసే రెండు మార్పులు. రెండూ మరమ్మతు కాదు. రెండూ వైఫల్యాన్ని మరింత ఆలస్యంగా, కారణం చెప్పడం కష్టమైన చోటికి నెడతాయి.
కొత్త అభ్యర్థన మరియు వినియోగదారు నిజంగా ఆధారపడే పునఃకనెక్షన్ ప్రవర్తనను పరీక్షించి ముగించండి. ఫిర్యాదుకు కారణమైన భారం క్రింద స్థిరత్వమే నమోదు చేయదగిన ఏకైక ఫలితం.