நெட்வொர்க் தாமதத்தை அளவிடுவது: ஒரு டெவலப்பரின் நடைமுறை வழிகாட்டி

நெட்வொர்க் லேட்டன்சியை அளவிட வேண்டுமா? ரவுண்ட்-ட்ரிப் டைம் (RTT) பற்றிய விரைவான தகவல்களைப் பெற, ping மற்றும் traceroute போன்ற எளிய, உள்ளமைக்கப்பட்ட கட்டளை வரி கருவிகளுடன் தொடங்கலாம். அல்லது, உங்கள் உலாவியின் டெவலப்பர் கருவிகளைத் திறந்து, தாமதங்கள் உங்கள் பயனர்கள் உண்மையில் அனுபவிப்பதை எவ்வாறு பாதிக்கின்றன என்பதைப் பார்க்கலாம்.

இந்த முறைகள் ஒரு தரவு பாக்கெட் ஒரு மூலத்திலிருந்து ஒரு இலக்கை அடைந்து மீண்டும் திரும்புவதற்கு எவ்வளவு நேரம் ஆகும் என்பதைப் பற்றிய விரைவான, பயனுள்ள ஸ்னாப்ஷாட்டை உங்களுக்கு வழங்குகின்றன.

லேட்டன்சியை அளவிடுவது ஏன் தவிர்க்க முடியாதது

"எப்படி" என்பதைப் பற்றி பேசுவதற்கு முன், "ஏன்" என்பதைப் பற்றி பேசுவோம். டெவலப்பர்கள் மற்றும் நெட்வொர்க் பொறியாளர்களுக்கு, லேட்டன்சி என்பது திரையில் உள்ள ஒரு எண் மட்டுமல்ல; இது முழு பயனர் அனுபவத்தையும் வடிவமைக்கும் கண்ணுக்குத் தெரியாத கை. இன்றைய பயன்பாடுகளில், மில்லிசெகண்டுகள் அனைத்தும். ஒரு சிறிய தாமதம் கூட ஒரு சேவை உடனடியாக செயல்படுவதற்கும், அது பழுதடைந்ததாக உணர்வதற்கும் உள்ள வித்தியாசமாக இருக்கலாம்.

உண்மையான உலக விளைவுகளைப் பற்றி சிந்தியுங்கள்:

• API ரெஸ்பான்சிவ்னஸ்: ஒரு மெதுவான API அழைப்பு ஒரு சங்கிலி விளைவை உருவாக்கலாம், பயனரின் சுயவிவரத்தை ஏற்றுவது முதல் ஒரு முக்கியமான கட்டணத்தைச் செயல்படுத்துவது வரை அனைத்தையும் தாமதப்படுத்தலாம்.
• நிகழ்நேர தரவு ஸ்ட்ரீம்கள்: ஆன்லைன் கேமிங், நேரடி வீடியோ அல்லது நிதி வர்த்தகத்திற்கு, குறைந்த மற்றும் நிலையான லேட்டன்சி என்பது முழுமையான அடிப்படையாகும். அது இல்லாமல், இந்த பயன்பாடுகள் வெறுமனே வேலை செய்யாது.
• பயனர் தக்கவைப்பு: மெதுவாக ஏற்றப்படும் வலைத்தளங்கள் மற்றும் பயன்பாடுகளுக்கும் அதிக பவுன்ஸ் விகிதங்களுக்கும் மற்றும் கைவிடப்பட்ட ஷாப்பிங் கார்டுகளுக்கும் இடையே ஒரு நேரடி தொடர்பு உள்ளது. இது லாபத்தை கடுமையாக பாதிக்கிறது.

முக்கிய லேட்டன்சி கருத்துக்களை வேறுபடுத்துதல்

நெட்வொர்க் லேட்டன்சியை துல்லியமாக அளவிட, நீங்கள் எதைப் பார்க்கிறீர்கள் என்பதை நீங்கள் அறிந்திருக்க வேண்டும். இரண்டு மிக அடிப்படையான கருத்துக்கள் ரவுண்ட்-ட்ரிப் டைம் (RTT) மற்றும் ஒன்-வே லேட்டன்சி.

RTT என்பது ஒரு சிக்னல் புள்ளி A இலிருந்து புள்ளி B க்கு சென்று மீண்டும் திரும்புவதற்கு எடுக்கும் மொத்த நேரம். இது நீங்கள் பார்க்கும் பொதுவான அளவீடு ஆகும், ஏனெனில் இதை அளவிடுவது எளிது - இணைப்பின் ஒரு முனையை அணுகினால் போதும்.

ஒன்-வே லேட்டன்சி, பெயர் குறிப்பிடுவது போல, தரவு ஒரு திசையில் மட்டுமே பயணிக்க எடுக்கும் நேரத்தை அளவிடுகிறது. இது சரியாகப் பெறுவதற்கு மிகவும் கடினமான அளவீடு ஆகும், ஏனெனில் இதற்கு இரண்டு முனைகளிலும் சரியாக ஒத்திசைக்கப்பட்ட கடிகாரங்கள் தேவை. இருப்பினும், இது சமச்சீரற்ற இணைப்புகளுக்கு மிகவும் துல்லியமான குறிகாட்டியாகும், அங்கு உங்கள் பதிவேற்றம் மற்றும் பதிவிறக்கப் பாதைகள் மிகவும் வித்தியாசமாக செயல்படுகின்றன.

நீங்கள் தீவிரமான சுமை செயல்திறன் சோதனையை செய்யும்போது இவை அனைத்தின் முக்கியத்துவமும் தெளிவாகிறது, அங்கு கோட்பாடு யதார்த்தத்தை சந்தித்து சிக்கல்கள் வெளிப்படும்.

சில எண்களைக் குறிப்பிட, நெட்வொர்க் கண்காணிப்பு வல்லுநர்கள் பொதுவாக லேட்டன்சியை இவ்வாறு வகைப்படுத்துகிறார்கள்:

• குறைந்த லேட்டன்சி: 50 மில்லிசெகண்டுகளுக்கு கீழ்
• மிதமான லேட்டன்சி: 50-150 ms
• அதிக லேட்டன்சி: 150 ms க்கு மேல்

எனது அனுபவத்தில், அருகிலுள்ள ஒரு சேவையகத்திற்கு ஒரு விரைவான சோதனை முற்றிலும் ஏற்றுக்கொள்ளக்கூடிய 20-40 ms ஐக் காட்டலாம். ஆனால் ஒரு கடலைக் கடக்க வேண்டிய போக்குவரத்துக்கு அந்த எண் எளிதாக 200 ms க்கு மேல் அதிகரிக்கலாம், இது உங்கள் பயன்பாட்டின் செயல்திறனுக்கு ஒரு பெரிய மாற்றமாக இருக்கலாம்.

நீங்கள் சந்திக்கும் சொற்களைப் புரிந்துகொள்ள, இங்கே ஒரு விரைவான குறிப்பு.

முக்கிய லேட்டன்சி கருத்துக்கள் ஒரு பார்வையில்

கருத்து	இது எதை அளவிடுகிறது	இது ஏன் முக்கியம்
லேட்டன்சி (பிங்)	ஒரு தரவு பாக்கெட் ஒரு மூலத்திலிருந்து ஒரு இலக்கை அடைந்து மீண்டும் திரும்புவதற்கு எடுக்கும் நேரம். மில்லிசெகண்டுகளில் (ms) அளவிடப்படுகிறது.	இது தாமதத்தின் மூல அளவீடு. கேமிங், VoIP மற்றும் வீடியோ கான்பரன்சிங் போன்ற நிகழ்நேர பயன்பாடுகளுக்கு குறைந்த லேட்டன்சி முக்கியமானது.
ரவுண்ட்-ட்ரிப் டைம் (RTT)	லேட்டன்சிக்கு ஒத்ததாக, இது ஒரு சிக்னல் அனுப்பப்படுவதற்கும், ஒரு ஒப்புதல் பெறப்படுவதற்கும் ஆகும் மொத்த நேரம்.	RTT என்பது ஒரு புள்ளியிலிருந்து லேட்டன்சியை அளவிடுவதற்கான பொதுவான மற்றும் நடைமுறை வழி, இது ping போன்ற கருவிகளுக்கு ஒரு முக்கிய அளவீடாக அமைகிறது.
ஒன்-வே லேட்டன்சி	ஒரு பாக்கெட் ஒரு திசையில் மூலத்திலிருந்து இலக்குக்கு பயணிக்க எடுக்கும் நேரம்.	குறிப்பாக சமச்சீரற்ற நெட்வொர்க்குகளுக்கு ஒரு விரிவான பார்வையை வழங்குகிறது, அங்கு பதிவேற்றம் மற்றும் பதிவிறக்கப் பாதைகள் வெவ்வேறு லேட்டன்சிகளைக் கொண்டுள்ளன.
ஜிட்டர்	காலப்போக்கில் லேட்டன்சியில் ஏற்படும் மாறுபாடு. இது பாக்கெட் வருகை நேரங்களின் சீரற்ற தன்மையை அளவிடுகிறது.	அதிக ஜிட்டர் அதிக லேட்டன்சியைப் போலவே மோசமானது, இது ஸ்ட்ரீமிங் மீடியா மற்றும் ஆன்லைன் அழைப்புகளுக்கு, தடுமாற்றம், பஃபரிங் மற்றும் கோளாறுகளை ஏற்படுத்துகிறது.
பேண்ட்வித்	ஒரு குறிப்பிட்ட நேரத்தில் ஒரு நெட்வொர்க் இணைப்பு வழியாக அனுப்பக்கூடிய அதிகபட்ச தரவு அளவு. Mbps அல்லது Gbps இல் அளவிடப்படுகிறது.	வேகத்துடன் அடிக்கடி குழப்பப்படுகிறது, பேண்ட்வித் என்பது திறன் பற்றியது. உங்களுக்கு அதிக பேண்ட்வித் இருந்தாலும் அதிக லேட்டன்சியால் பாதிக்கப்படலாம்.

இந்த கருத்துக்கள் எந்தவொரு நெட்வொர்க் செயல்திறன் சிக்கலையும் புரிந்துகொள்வதற்கான அடிப்படைக் கட்டுமானத் தொகுதிகள்.

இங்குதான் அணுகக்கூடிய, ஒருங்கிணைந்த கருவிகள் மிகவும் முக்கியத்துவம் பெறுகின்றன. சிக்கலான கண்டறியும் தொகுப்புகளை இயக்குவதற்குப் பதிலாக, நவீன உலாவி நீட்டிப்புகள் மற்றும் மேம்பாட்டுக் கருவிகள் உங்கள் பணிப்பாய்விலிருந்து வெளியேறாமல் உங்களுக்குத் தேவையான நுண்ணறிவுகளை வழங்க முடியும். இது லேட்டன்சி அளவீட்டை சிறந்த மென்பொருளை உருவாக்குவதிலும் பராமரிப்பதிலும் ஒரு சிரமமில்லாத, வழக்கமான பகுதியாக மாற்றுவதாகும்.

கட்டளை வரி லேட்டன்சி கருவிகளுடன் உங்கள் கைகளை அழுக்காக்குதல்

உங்கள் நெட்வொர்க்கின் செயல்திறனை உண்மையில் உணர, நீங்கள் டெர்மினலைத் திறக்க வேண்டும். கட்டளை வரி என்பது உங்கள் இணைப்பு பற்றிய மூல, வடிகட்டப்படாத தரவை வழங்கும் அடிப்படைக் கருவிகளைக் கண்டுபிடிக்கும் இடம். உங்களுக்கும் ஒரு இலக்குக்கும் இடையில் நகரும் பாக்கெட்டுகளுடன் உண்மையில் என்ன நடக்கிறது என்பதைப் பார்ப்பது பற்றியது, மேலும் லேட்டன்சியை அளவிடுவதில் தீவிரமாக இருக்கும் எந்த டெவலப்பருக்கும் இது அத்தியாவசிய முதல் படியாகும்.

கிளாசிக், செல்ல வேண்டிய பயன்பாடு ping. இது அழகாக எளிமையானது: இது ஒரு சிறிய தரவு பாக்கெட்டை (ஒரு ICMP எக்கோ கோரிக்கை) ஒரு சேவையகத்திற்கு அனுப்புகிறது, அது திரும்பி வர காத்திருக்கிறது. அந்த எளிய ரவுண்ட் ட்ரிப் ரவுண்ட்-ட்ரிப் டைம் (RTT) ஐக் கணக்கிடுவதற்கான அடிப்படையாகும், மேலும் இது ஒரு இணைப்பில் உடனடி சுகாதார பரிசோதனையை உங்களுக்கு வழங்குகிறது.

பிங் மூலம் உங்கள் முதல் லேட்டன்சி சோதனை

ஒரு ping சோதனையை இயக்குவது மிகவும் எளிதானது. உங்கள் டெர்மினல் அல்லது கட்டளை வரியில், ping என தட்டச்சு செய்து, நீங்கள் சோதிக்க விரும்பும் டொமைனைப் பின்தொடரவும்.

இயல்பாக, macOS மற்றும் Linux இல் ping எப்போதும் இயங்கிக் கொண்டிருக்கும், அதே நேரத்தில் Windows நான்கு பாக்கெட்டுகளை மட்டுமே அனுப்பி நிறுத்திவிடும். எந்தவொரு உண்மையான பகுப்பாய்விற்கும், இதை நீங்கள் கட்டுப்படுத்த வேண்டும். பத்து அல்லது இருபது பாக்கெட்டுகளை அனுப்புவது, ஒரு சில பாக்கெட்டுகளை அனுப்புவதை விட, இணைப்பின் நிலைத்தன்மை பற்றிய மிகவும் நம்பகமான படத்தைக் கொடுக்கும்.

அது முடிந்ததும், முக்கியமான எண்களுடன் ஒரு நேர்த்தியான சுருக்கத்தைப் பெறுவீர்கள்:

• அனுப்பப்பட்ட/பெறப்பட்ட பாக்கெட்டுகள்: வழியில் ஏதேனும் தரவு இழக்கப்பட்டதா என்பதை இது உங்களுக்குத் தெரிவிக்கும். ஒரு சிறிய அளவு பாக்கெட் இழப்பு கூட நெட்வொர்க் சிக்கலுக்கு ஒரு பெரிய சிவப்பு எச்சரிக்கை ஆகும்.
• ரவுண்ட்-ட்ரிப் குறைந்தபட்சம்/சராசரி/அதிகபட்சம்/mdev: இவை உங்கள் முக்கிய லேட்டன்சி புள்ளிவிவரங்கள். நீங்கள் சிறந்த நேரத்தைப் பெறுவீர்கள் (min), சராசரி (avg), மற்றும் மோசமான நேரம் (max). mdev (சராசரி விலகல்) என்பது உங்கள் ஜிட்டர் அளவீடு - ஒரு பாக்கெட்டிலிருந்து அடுத்த பாக்கெட்டிற்கு லேட்டன்சி எவ்வளவு மாறுபடுகிறது.

உங்கள் குறைந்தபட்ச மற்றும் அதிகபட்ச RTT க்கு இடையிலான இடைவெளியில் கவனம் செலுத்துங்கள். அது அகலமாக இருந்தால், உங்கள் இணைப்பு நிலையற்றது, சராசரி நன்றாக இருந்தாலும் கூட. இந்த ஜிட்டர் வீடியோ அழைப்புகள் அல்லது கேமிங் போன்ற நிகழ்நேர பயன்பாடுகளுக்கு, தொடர்ந்து சற்று மெதுவாக இருக்கும் இணைப்பை விட மிகவும் இடையூறாக இருக்கும்.

சராசரி RTT-ஐ மேலோட்டமாகப் பார்ப்பது ஒரு பொதுவான தவறு. சராசரியாக 50ms நன்றாகத் தோன்றலாம், ஆனால் உங்கள் குறைந்தபட்சம் 20ms ஆகவும், அதிகபட்சம் 250ms ஆகவும் இருந்தால், பயனர் அனுபவம் சீரற்றதாகவும் நம்பகத்தன்மையற்றதாகவும் இருக்கும். ஜிட்டரைப் புரிந்துகொள்ள எப்போதும் முழு வரம்பையும் பாருங்கள்.

டிரேசர்ரூட் மற்றும் MTR உடன் தடத்தைப் பின்தொடர்தல்

அப்படியானால், ping அதிக தாமதம் அல்லது பாக்கெட் இழப்பைக் காட்டும்போது நீங்கள் என்ன செய்வீர்கள்? சிக்கல் எங்கு உள்ளது என்பதைக் கண்டுபிடிப்பதுதான் உங்கள் அடுத்த வேலை. அதற்காகத்தான் traceroute (அல்லது விண்டோஸில் tracert) உள்ளது. இது உங்கள் பாக்கெட்டுகள் செல்லும் முழுப் பாதையையும் வரைபடமாக்குகிறது, உங்கள் இயந்திரத்திற்கும் இறுதி இலக்கிற்கும் இடையில் உள்ள ஒவ்வொரு "ஹாப்" - ஒவ்வொரு ரூட்டரையும் காட்டுகிறது.

traceroute வெளியீட்டில் உள்ள ஒவ்வொரு வரியும் ஒரு ஹாப் ஆகும், மேலும் அது பொதுவாக அந்த புள்ளிக்கு மூன்று தனித்தனி தாமத அளவீடுகளைக் காட்டுகிறது. இது பாதையில் உள்ள ஒரு குறிப்பிட்ட ரூட்டர் பெரிய வேகக்குறைவு அல்லது பாக்கெட்டுகளைக் கைவிடுகிறதா என்பதைக் கண்டறிய உதவுகிறது.

ஆனால் traceroute என்பது ஒருமுறை மட்டுமே எடுக்கப்படும் ஸ்னாப்ஷாட். மேலும் மாறும், தொடர்ச்சியான பார்வைக்கு, எனக்குத் தெரிந்த பெரும்பாலான நெட்வொர்க் வல்லுநர்கள் MTR (My Traceroute) ஐப் பயன்படுத்துகிறார்கள். MTR என்பது ping மற்றும் traceroute ஐ இணைக்கும் ஒரு சூப்பர்சார்ஜ் செய்யப்பட்ட கருவி போன்றது. இது பாதையில் உள்ள ஒவ்வொரு ஹாப்பிற்கும் தொடர்ந்து பாக்கெட்டுகளை அனுப்புகிறது, ஒவ்வொரு புள்ளியிலும் தாமதம் மற்றும் பாக்கெட் இழப்பின் நேரடி, புதுப்பிக்கும் காட்சியைக் காட்டுகிறது. இது ஒரு traceroute தவறவிடக்கூடிய இடைப்பட்ட சிக்கல்களைக் கண்டறிவதில் நம்பமுடியாத அளவிற்கு பயனுள்ளதாக இருக்கும்.

உங்கள் கருவித் தேர்வு ஏன் முக்கியம்

நீங்கள் தேர்ந்தெடுக்கும் கருவி மற்றும் அதை நீங்கள் எவ்வாறு கட்டமைக்கிறீர்கள் என்பது உங்கள் முடிவுகளை வியத்தகு முறையில் மாற்றலாம். இது அதிவேக, குறைந்த தாமத சூழல்களில், கிளவுட் டேட்டா சென்டர்கள் போன்ற இடங்களில் குறிப்பாக உண்மை.

எண்கள் எவ்வளவு வித்தியாசமாக இருக்கும் என்பது உண்மையில் கண்களைத் திறக்கும். Google Cloud நடத்திய ஒரு விரிவான சோதனையில், ஒரு நிலையான ping சோதனை சராசரியாக 146 மைக்ரோசெகண்ட்ஸ் RTT ஐப் பதிவு செய்தது. ஆனால் அவர்கள் இடைநிறுத்தமின்றி தொடர்ச்சியாக பரிவர்த்தனைகளை அனுப்பும் மற்றொரு கருவியைப் பயன்படுத்தியபோது, RTT வெறும் 66.59 மைக்ரோசெகண்ட்ஸ் ஆகக் குறைந்தது - இரண்டு மடங்குக்கும் மேல் வேகமாக!

ping சில சமயங்களில் தாமதத்தை ஏன் மிகைப்படுத்திக் காட்டுகிறது என்பதற்கு இது ஒரு சரியான எடுத்துக்காட்டு. ஒரு கருவி எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்வது நம்பகமான அளவீடுகளைப் பெறுவதற்கு முக்கியம் என்பதைக் காட்டுகிறது.

iperf உடன் உங்கள் இணைப்பின் அதிகபட்ச வேகத்தைக் கண்டறிதல்

தாமதம் எப்போதும் முழுமையான படம் அல்ல. சில சமயங்களில் உங்கள் இணைப்பு உண்மையில் எவ்வளவு அதிகபட்ச தரவை அனுப்ப முடியும் - அதன் அலைவரிசை - என்பதை நீங்கள் தெரிந்து கொள்ள வேண்டும். அந்த வேலைக்கு, நீங்கள் விரும்பும் கருவி iperf.

ping தாமதத்தை அளவிடும்போது, iperf என்பது முழுவதுமாக த்ரூபுட் பற்றியது. இது ஒரு கிளையன்ட்-சர்வர் இணைப்பை அமைத்து, பின்னர் ஒரு குறிப்பிட்ட காலத்திற்கு அவற்றுக்கிடையே முடிந்தவரை அதிக தரவை அனுப்புவதன் மூலம் செயல்படுகிறது.

iperf ஐப் பயன்படுத்த, உங்களுக்கு இரண்டு இயந்திரங்கள் தேவைப்படும்:

1. ஒரு இயந்திரத்தில், நீங்கள் iperf ஐ சர்வர் பயன்முறையில் இயக்குவீர்கள். அது அங்கேயே அமர்ந்து ஒரு இணைப்புக்காகக் காத்திருக்கும்.
2. மற்ற இயந்திரத்தில், நீங்கள் iperf ஐ கிளையன்ட் பயன்முறையில் இயக்குவீர்கள், அதை சர்வரின் முகவரியை நோக்கிச் சுட்டிக்காட்டுவீர்கள்.

கிளையன்ட் இணைக்கும் மற்றும் சோதனை தொடங்கும். வெளியீடு மாற்றப்பட்ட மொத்த தரவு மற்றும், மிக முக்கியமாக, மெகாபிட்கள் அல்லது ஜிகாபிட்கள்/வினாடியில் உள்ள பிட்ரேட் (உங்கள் அலைவரிசை) ஆகியவற்றைக் காட்டுகிறது. ஒரு நெட்வொர்க் இணைப்பை அழுத்த-சோதனை செய்து, அது உண்மையில் எதைக் செய்யக்கூடியது என்பதைக் கண்டறிய இது சரியான வழி.

பயனரின் கண்ணோட்டத்தில் தாமதத்தை அளவிடுதல்

கட்டளை வரி கருவிகள் உங்கள் நெட்வொர்க்கின் மூல, வடிகட்டப்படாத தோற்றத்தை உங்களுக்கு வழங்கினாலும், ஒரு வலை பயன்பாட்டிற்கு உண்மையில் முக்கியமான தாமதம் என்பது இறுதிப் பயனர் உண்மையில் அனுபவிப்பதுதான். இங்குதான் நாம் நமது கவனத்தை டெர்மினலில் இருந்து உலாவிக்கே மாற்றுகிறோம். உலாவியில் என்ன நடக்கிறது என்பது செயல்திறனைப் பற்றி மிகவும் செழுமையான, பொருத்தமான கதையைச் சொல்கிறது.

இது ஒரு ஒற்றை பாக்கெட்டின் ரவுண்ட் ட்ரிப் பற்றியது மட்டுமல்ல. ஒரு பயனர் உணரும் தாமதம் என்பது DNS தேடல்கள், TCP ஹேண்ட்ஷேக்குகள், TLS பேச்சுவார்த்தைகள், சர்வர் செயலாக்க நேரம் மற்றும் நிச்சயமாக, திரையில் உள்ளடக்கத்தை உண்மையில் ரெண்டர் செய்ய எடுக்கும் நேரம் ஆகியவற்றின் சிக்கலான கலவையாகும். அதிர்ஷ்டவசமாக, நவீன உலாவிகள் இந்த முழு செயல்முறையையும் பகுப்பாய்வு செய்ய சக்திவாய்ந்த உள்ளமைக்கப்பட்ட கருவிகளுடன் வருகின்றன.

உலாவி டெவலப்பர் கருவிகளில் மூழ்குதல்

ஒவ்வொரு முக்கிய உலாவியும் - Chrome, Firefox, Edge, Safari - டெவலப்பர் கருவிகளின் தொகுப்புடன் வருகிறது. இந்த கருவிகளில் உள்ள "நெட்வொர்க்" தாவல் உங்கள் தளம் எவ்வாறு ஏற்றப்படுகிறது என்பதைப் புரிந்துகொள்வதற்கான உங்கள் கட்டளை மையமாகும். இது அனைத்தையும் ஒரு நீர்வீழ்ச்சி விளக்கப்படத்தில் வைக்கிறது, இது ஒரு பக்கத்தை ரெண்டர் செய்ய உலாவி செய்யும் ஒவ்வொரு கோரிக்கையின் காட்சிப் பிரிவாகும்.

இந்த நீர்வீழ்ச்சி பார்வை விலைமதிப்பற்றது. ஆரம்ப HTML ஆவணம் மற்றும் CSS ஸ்டைல்ஷீட்கள் முதல் படங்கள் மற்றும் API அழைப்புகள் வரை ஒவ்வொரு சொத்தையும் பதிவிறக்க எவ்வளவு நேரம் எடுத்தது என்பதை நீங்கள் துல்லியமாகப் பார்க்கலாம். மிக முக்கியமாக, இது ஒவ்வொரு கோரிக்கையின் வாழ்க்கைச் சுழற்சியையும் தனித்தனி கட்டங்களாகப் பிரிக்கிறது:

• DNS தேடல்: ஒரு டொமைன் பெயரை ஒரு IP முகவரிக்குத் தீர்க்க எடுக்கும் நேரம்.
• ஆரம்ப இணைப்பு: சர்வர் உடன் ஒரு TCP இணைப்பை நிறுவ செலவழித்த நேரம்.
• SSL/TLS ஹேண்ட்ஷேக்: ஒரு பாதுகாப்பான இணைப்பை அமைக்கத் தேவையான ஓவர்ஹெட்.
• முதல் பைட்டிற்கான நேரம் (TTFB): இது ஒரு பெரிய விஷயம். சர்வரில் இருந்து முதல் பைட்டை பெறுவதற்கு உலாவி எவ்வளவு நேரம் காத்திருந்தது என்பதை இது அளவிடுகிறது.
• உள்ளடக்க பதிவிறக்கம்: வளத்தை உண்மையில் பதிவிறக்க செலவழித்த நேரம்.

உதாரணமாக, ஒரு உயர் TTFB என்பது ஒரு மந்தமான பின்தளம் அல்லது சர்வர் பக்க செயலாக்க சிக்கலின் ஒரு கிளாசிக் அறிகுறியாகும் - ஒரு எளிய ping சோதனை ஒருபோதும் கண்டறிய முடியாத ஒன்று. இந்த நீர்வீழ்ச்சியை பகுப்பாய்வு செய்வதன் மூலம், ரெண்டரிங்கைத் தடுக்கும் அல்லது ஏற்றப்படுவதற்கு அதிக நேரம் எடுக்கும் வளங்களை நீங்கள் விரைவாகக் கண்டறியலாம்.

எனது அனுபவத்திலிருந்து ஒரு முக்கிய குறிப்பு என்னவென்றால், மொத்த ஏற்ற நேரத்தை மட்டும் பார்க்காமல், நீர்வீழ்ச்சியில் உள்ள மிக நீளமான பட்டிகளைக் கண்டறிய வேண்டும். ஒரு ஒற்றை மேம்படுத்தப்படாத படம் அல்லது ஒரு மெதுவான மூன்றாம் தரப்பு API முழுப் பக்கத்தையும் பிணையாக வைத்திருக்கலாம், தளத்தின் மற்ற பகுதிகள் மின்னல் வேகத்தில் இருந்தாலும் மோசமான பயனர் அனுபவத்தை உருவாக்கலாம்.

நேர API களுடன் நிரல் ரீதியான அளவீடு

மேலும் தானியங்கு மற்றும் துல்லியமான அளவீடுகளுக்கு, நீங்கள் உலாவியின் உள்ளமைக்கப்பட்ட JavaScript API களைப் பயன்படுத்தலாம். Navigation Timing API மற்றும் Resource Timing API ஆகியவை டெவலப்பர் கருவிகளில் நீங்கள் காணும் அதே விரிவான செயல்திறன் தரவை நிரல் ரீதியாக அணுக உங்களுக்கு வழங்குகின்றன. உலகெங்கிலும் உள்ள உண்மையான பார்வையாளர்களுக்கு உங்கள் தளம் எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்ள உண்மையான பயனர் கண்காணிப்பு (RUM) தரவைச் சேகரிக்க இது சரியானது.

உலாவியின் கன்சோலில் சில வரிகள் JavaScript மூலம் இந்த அளவீடுகளை நீங்கள் பெறலாம். எடுத்துக்காட்டாக, முக்கிய பக்க ஏற்றத்திற்கான முக்கிய செயல்திறன் நேரங்களைப் பெற, நீங்கள் performance.getEntriesByType('navigation') ஐப் பயன்படுத்தலாம். இது மதிப்புமிக்க நேரமுத்திரைகளுடன் நிரம்பிய ஒரு பொருளைத் தருகிறது.

அந்த தரவுகளிலிருந்து, நீங்கள் முக்கியமான அளவீடுகளைக் கணக்கிடலாம்:

• DNS தேடல் நேரம்: domainLookupEnd - domainLookupStart
• TCP ஹேண்ட்ஷேக் நேரம்: connectEnd - connectStart
• முதல் பைட்டிற்கான நேரம் (TTFB): responseStart - requestStart
• மொத்த பக்க ஏற்ற நேரம்: loadEventEnd - startTime

இந்த அணுகுமுறை தனிப்பயன் டாஷ்போர்டுகளை உருவாக்க அல்லது உங்கள் பகுப்பாய்வு கருவிகளுக்கு செயல்திறன் தரவை அனுப்ப உங்களை அனுமதிக்கிறது, இது உங்கள் பயன்பாட்டின் உண்மையான உலக செயல்திறனைப் பற்றிய தொடர்ச்சியான துடிப்பை உங்களுக்கு வழங்குகிறது. வலை மேம்பாட்டில், படங்களை மேம்படுத்துவது இந்த அளவீடுகளை மேம்படுத்துவதற்கான ஒரு பொதுவான வழியாகும்; ஆர்வமுள்ளவர்களுக்கு, உங்கள் வலைத்தளத்திற்கான சிறந்த பட வடிவத்தைத் தேர்ந்தெடுப்பது குறித்த பயனுள்ள வழிகாட்டி எங்களிடம் உள்ளது.

ஒருங்கிணைந்த கருவிகளுடன் சரிபார்ப்புகளை நெறிப்படுத்துதல்

டெர்மினல், உலாவி டெவ் கருவிகள் மற்றும் தனிப்பயன் ஸ்கிரிப்ட்களுக்கு இடையில் குதிப்பது விரைவாகப் பழையதாகிவிடும். இங்குதான் ஒருங்கிணைந்த உலாவி நீட்டிப்புகள் இந்த சரிபார்ப்புகளை ஒன்றிணைப்பதன் மூலம் உங்கள் பணிப்பாய்வை உண்மையில் மென்மையாக்க முடியும். எடுத்துக்காட்டாக, ShiftShift Extensions தொகுப்பில் ஒரு உள்ளமைக்கப்பட்ட வேக சோதனை கருவி உள்ளது, அதை நீங்கள் எந்த தாவலிலிருந்தும் உடனடியாகத் திறக்கலாம்.

இது உங்கள் இணைப்பின் பதிவிறக்க வேகம், பதிவேற்ற வேகம் மற்றும் தாமதத்தை ஒரு தனி வலைத்தளத்திற்குச் செல்லாமலோ அல்லது ஒரு டெர்மினலைத் திறக்காமலோ விரைவான, தனியுரிமை-மையப்படுத்தப்பட்ட வழியில் அளவிட உங்களுக்கு வழங்குகிறது. இது ஒரு பெரிய கருவித்தொகுப்பின் ஒரு பகுதியாக இருப்பதால், நீங்கள் ஒரு வேகச் சரிபார்ப்பை இயக்கலாம், ஒரு JSON பதிலைப் வடிவமைக்கலாம் மற்றும் ஒரு குக்கீயை ஒரே ஒருங்கிணைந்த கட்டளைப் பலகத்திலிருந்து சரிபார்க்கலாம். இந்த வகையான ஒருங்கிணைப்பு செயல்திறன் சரிபார்ப்புகளை தினசரி மேம்பாட்டுப் பணியின் ஒரு இயற்கையான, உராய்வு இல்லாத பகுதியாக ஆக்குகிறது.

உண்மையில் உங்களுக்கு ஏதாவது சொல்லும் தாமத சோதனையை எவ்வாறு வடிவமைப்பது

யார் வேண்டுமானாலும் ஒரு ping கட்டளையை அனுப்பி ஒரு எண்ணைப் பெறலாம். ஆனால் நீங்கள் உண்மையில் நம்பக்கூடிய தரவு—உண்மையான முடிவுகளை எடுக்க உதவும் தரவு—வேண்டுமானால், நீங்கள் மிகவும் கவனமாக இருக்க வேண்டும். ஒரு தனிப்பட்ட, தனிமைப்படுத்தப்பட்ட அளவீடு என்பது ஒரு குறிப்பிட்ட நேரத்தில் எடுக்கப்பட்ட ஒரு படம் மட்டுமே. உங்கள் நெட்வொர்க்கின் நடத்தையை உண்மையாகப் புரிந்துகொள்ள, நீங்கள் ஒரு துப்பறிவாளர் போல சிந்திக்க வேண்டும், நீங்கள் எங்கிருந்து சோதிக்கிறீர்கள், எவ்வளவு அடிக்கடி சோதிக்கிறீர்கள், மற்றும் நீங்கள் உண்மையில் எதைத் தேடுகிறீர்கள் என்பதைக் கருத்தில் கொள்ள வேண்டும்.

நன்கு வடிவமைக்கப்பட்ட சோதனை, மூல எண்களைச் செயல்படக்கூடிய நுண்ணறிவுகளாக மாற்றுகிறது. மோசமாக வடிவமைக்கப்பட்டதா? அது வெறும் சத்தம்.

கீழே உள்ள வரைபடம், ஒரு பயனர் ஒரு வலைப்பக்கத்தை ஏற்றும்போது உணரும் அனைத்து சிறிய தாமதங்களையும் உடைக்கிறது. ஒரு எளிய நெட்வொர்க் பிங் முழு கதையையும் சொல்லத் தொடங்கவில்லை என்பதை இது ஒரு சிறந்த நினைவூட்டலாகும்.

நீங்கள் பார்க்கிறபடி, ஆரம்ப DNS தேடலில் இருந்து இறுதி ரெண்டர் வரை, பல படிகள் மொத்த காத்திருப்பு நேரத்திற்கு பங்களிக்கின்றன.

உங்கள் சோதனை இறுதிப் புள்ளிகளைத் தேர்ந்தெடுத்தல்

நம்பகமான சோதனையின் முதல் விதி என்னவென்றால், புவியியல் முக்கியமானது. நியூயார்க்கில் உள்ள உங்கள் அலுவலகத்திலிருந்து நியூ ஜெர்சியில் உள்ள ஒரு சேவையகத்திற்கு ஒரு சோதனை, டோக்கியோவில் உள்ள உங்கள் வாடிக்கையாளர்களின் அனுபவத்தைப் பற்றி உங்களுக்கு எதுவும் சொல்லாது. ஒரு யதார்த்தமான படத்தைப் பெற, உங்கள் பயனர் தளத்தை உண்மையில் பிரதிபலிக்கும் பல்வேறு இடங்களிலிருந்து நீங்கள் சோதிக்க வேண்டும்.

உங்கள் இறுதிப் புள்ளிகளின் பட்டியல் சில முக்கிய பகுதிகளை உள்ளடக்கியிருக்க வேண்டும்:

• உங்கள் மிகப்பெரிய பயனர் மையங்கள்: உங்கள் பெரும்பாலான வாடிக்கையாளர்கள் எங்கு வாழ்கிறார்கள்? அங்கிருந்து சோதிக்கவும்.
• கண்டம் தாண்டிய பாதைகள்: தரவு ஒரு கடலைக் கடக்கும்போது என்ன நடக்கிறது என்று பாருங்கள். நீண்ட தூர செயல்திறனைப் புரிந்துகொள்ள ஐரோப்பா மற்றும் வட அமெரிக்கா அல்லது ஆசியா மற்றும் அமெரிக்கா இடையே சோதிக்கவும்.
• உங்கள் கிளவுட் பகுதிகள்: நீங்கள் AWS, Azure அல்லது GCP இல் இருந்தால், நீங்கள் நம்பியிருக்கும் குறிப்பிட்ட தரவு மையப் பகுதிகளுக்கு மற்றும் அவற்றுக்கிடையே இணைப்பைச் சோதிக்கவும்.

உங்கள் சோதனைகளை இப்படிப் பரப்புவது உலகளாவிய செயல்திறனின் மிகவும் துல்லியமான வரைபடத்தை உருவாக்குகிறது. நீங்கள் இல்லையெனில் முற்றிலும் தவறவிட்ட பிராந்திய-குறிப்பிட்ட சிக்கல்களைக் கண்டறிய இது உதவுகிறது. உங்கள் டொமைன் அமைப்பை இருமுறை சரிபார்க்க இது ஒரு நல்ல தருணம்; டொமைன் கிடைக்கும் தன்மையை எவ்வாறு சரிபார்ப்பது மற்றும் தொடர்புடைய உள்ளமைவுகள் குறித்து பயனுள்ள உதவிக்குறிப்புகளை நீங்கள் காணலாம், எல்லாம் சரியாக இருப்பதை உறுதிசெய்ய.

சரியான சோதனை தாளத்தைக் கண்டறிதல்

நெட்வொர்க் நிலைமைகள் தொடர்ந்து மாறிக்கொண்டே இருக்கின்றன. அவை நாள் முழுவதும், வாரம் முழுவதும், ஏன் நிமிடத்திற்கு நிமிடம் கூட மாறுகின்றன. செவ்வாய்க்கிழமை அதிகாலை 3 மணிக்கு நடத்தப்படும் ஒரு சோதனை அருமையாகத் தோன்றலாம், ஆனால் உங்கள் உச்ச போக்குவரத்து வெள்ளிக்கிழமை பிற்பகல் 2 மணிக்கு அனைவரும் ஆன்லைனில் இருக்கும்போது ஏற்பட்டால் அந்த முடிவு பயனற்றது.

ஒரு உண்மையான அடிப்படையைப் பெற, நீங்கள் காலப்போக்கில் தொடர்ந்து சோதிக்க வேண்டும். இதை கலந்து செய்யுங்கள்:

• உச்ச வணிக நேரங்களில் சோதனைகளை இயக்கவும்.
• இரவு நேர பராமரிப்பு சாளரங்களுக்காக சிலவற்றை திட்டமிடவும்.
• வார இறுதி நாட்களை மறந்துவிடாதீர்கள், அப்போது போக்குவரத்து முறைகள் முற்றிலும் வேறுபட்டதாக இருக்கலாம்.

தரவை மீண்டும் மீண்டும் மாதிரி செய்வதன் மூலம், சீரற்ற ஏற்ற இறக்கங்களை நீங்கள் சீராக்கலாம். ஒவ்வொரு வார நாளும் மதிய உணவுக்குப் பிறகு நெட்வொர்க் நெரிசலாவது போன்ற தொடர்ச்சியான சிக்கல்களை நீங்கள் இப்படித்தான் கண்டறிகிறீர்கள்.

ஜிட்டர் பற்றி மறந்துவிடாதீர்கள்

சராசரி தாமதம் ஒரு திடமான தொடக்கப் புள்ளி, ஆனால் இது பெரும்பாலும் ஒரு மோசமான சிக்கலை மறைக்கிறது: ஜிட்டர். ஜிட்டர் என்பது காலப்போக்கில் உங்கள் தாமதத்தில் ஏற்படும் மாறுபாடு ஆகும். இதைப் பற்றி யோசித்துப் பாருங்கள்—ஒரு நிலையான இணைப்பு, கணிக்கக்கூடிய 80ms தாமதத்துடன், சராசரியாக 50ms ஆனால் 10ms மற்றும் 200ms இடையே காட்டுத்தனமாக அலைபாயும் ஒரு இணைப்பை விட நிகழ்நேர பயன்பாடுகளுக்கு பெரும்பாலும் சிறந்தது.

ஜிட்டர் என்பது VoIP அழைப்புகள், வீடியோ கான்பரன்ஸ்கள் அல்லது ஆன்லைன் கேமிங் போன்ற நிகழ்நேர விஷயங்களுக்கு பயனர் அனுபவத்தின் அமைதியான கொலையாளி. அதிக ஜிட்டர் என்பது துண்டிக்கப்பட்ட ஆடியோ, உறைந்த வீடியோ மற்றும் எரிச்சலூட்டும் லேக் ஸ்பைக்குகளுக்கு காரணமாகிறது, இது ஒரு பயன்பாட்டை முற்றிலும் செயலிழந்தது போல் உணர வைக்கிறது, சராசரி தாமதம் காகிதத்தில் நன்றாகத் தோன்றினாலும் கூட.

ஜிட்டரைப் புரிந்துகொள்வது சராசரியைத் தாண்டி பார்ப்பதாகும். இது ஒரு மறைக்கப்பட்ட வில்லன், ஏனெனில் சராசரிகள் மட்டும் ஏன் இவ்வளவு தவறாக வழிநடத்தக்கூடியவை என்பதை இது வெளிப்படுத்துகிறது. உதாரணமாக, Pandora FMS இலிருந்து கிடைத்த தரவு, 30ms க்கும் அதிகமான ஜிட்டர் கேமிங்கில் பாக்கெட் இழப்பு விகிதங்களை 15% ஆக உயர்த்தும் என்பதைக் காட்டுகிறது—இது ஒரு விளையாட்டை விளையாட முடியாததாக மாற்ற போதுமானது. உங்கள் தாமத முடிவுகளின் நிலையான விலகலைக் கணக்கிடுவது அந்த நிலையற்ற தன்மையை ஒரு எண்ணில் வைப்பதற்கான முதல் படியாகும்.

தாமத சோதனை வடிவமைப்பு சரிபார்ப்புப் பட்டியல்

இவை அனைத்தையும் ஒருங்கிணைக்க, உங்களுக்கு வழிகாட்ட ஒரு விரைவான சரிபார்ப்புப் பட்டியல் இங்கே. இந்த படிகளைப் பின்பற்றுவது நீங்கள் சேகரிக்கும் தரவு துல்லியமானது மற்றும் உண்மையாக பயனுள்ளது என்பதை உறுதிப்படுத்த உதவும்.

சரிபார்ப்புப் பட்டியல் உருப்படி	இது ஏன் முக்கியம்	செயல்படக்கூடிய குறிப்பு
தெளிவான இலக்குகளை வரையறுக்கவும்	நீங்கள் வரையறுக்காததை அளவிட முடியாது. நீங்கள் ஒரு குறிப்பிட்ட சிக்கலை சரிசெய்கிறீர்களா அல்லது ஒரு அடிப்படையை நிறுவுகிறீர்களா?	நீங்கள் தொடங்குவதற்கு முன் உங்கள் நோக்கத்தை எழுதுங்கள். "தென்கிழக்கு ஆசியாவில் உள்ள பயனர்களுக்கான லேக்கை கண்டறிதல்" என்பது "தாமதத்தை சரிபார்த்தல்" என்பதை விட சிறந்த இலக்காகும்.
பல்வேறு இறுதிப் புள்ளிகளைத் தேர்ந்தெடுக்கவும்	ஒரு ஒற்றை பாதை உங்கள் உலகளாவிய பயனர் அனுபவத்தை பிரதிநிதித்துவப்படுத்தாது.	3-5 இடங்களைத் தேர்ந்தெடுக்கவும்: ஒன்று உள்ளூர், ஒன்று மற்றொரு கண்டத்தில், மற்றும் உங்கள் முக்கிய பயனர் சந்தைகளில் சில.
ஒரு தாளத்தை நிறுவவும்	ஒரு முறை சோதனைகள் உச்ச நேர நெரிசல் போன்ற நேர அடிப்படையிலான வடிவங்களைத் தவறவிடுகின்றன.	நெட்வொர்க் நடத்தையின் முழு சுழற்சியைப் பிடிக்க ஒரு வாரத்திற்கு ஒவ்வொரு மணி நேரமும் தானாக இயங்க சோதனைகளை திட்டமிடவும்.
ஜிட்டரை அளவிடவும்	சராசரிகள் நிகழ்நேர பயன்பாடுகளை அழிக்கும் ஒழுங்கற்ற செயல்திறனை மறைக்கின்றன.	சராசரி RTT ஐ மட்டும் பார்க்க வேண்டாம். நிலையான விலகலைக் கணக்கிடுங்கள் அல்லது min/max/avg தாமதத்தைக் காட்டும் mtr போன்ற ஒரு கருவியைப் பயன்படுத்தவும்.
சரியான கருவிகளைப் பயன்படுத்தவும்	ping ஒரு விரைவான சோதனைக்கு நல்லது, ஆனால் mtr அல்லது iperf போன்ற கருவிகள் ஆழமான நுண்ணறிவுகளை வழங்குகின்றன.	வலை செயல்திறனுக்கு, உலாவி dev கருவிகளைப் பயன்படுத்தவும். மூல நெட்வொர்க் பாதைகளுக்கு, mtr ஒரு சிறந்த தேர்வாகும்.
எல்லாவற்றையும் ஆவணப்படுத்தவும்	ஆறு மாதங்களுக்குப் பிறகு உங்கள் சோதனைக்குப் பின்னால் உள்ள "ஏன்" என்பதை நீங்கள் மறந்துவிடுவீர்கள்.	ஒரு எளிய பதிவை வைத்திருங்கள்: தேதி, நேரம், இறுதிப் புள்ளிகள், பயன்படுத்தப்பட்ட கருவி மற்றும் நீங்கள் கவனித்ததைப் பற்றிய ஒரு சுருக்கமான குறிப்பு.

முறையாக இருப்பதன் மூலம், நீங்கள் தாமதத்தை அளவிடுவதிலிருந்து அதை உண்மையாகப் புரிந்துகொள்வதற்கு நகர்கிறீர்கள். இந்த சிந்தனைமிக்க அணுகுமுறைதான் ஒரு சீரற்ற எண்ணை ஒரு நம்பகமான செயல்திறன் காட்டியிலிருந்து பிரிக்கிறது.

எண்களைப் புரிந்துகொள்வது (மற்றும் எதைத் தவிர்ப்பது)

சரி, நீங்கள் உங்கள் சோதனைகளை நடத்தி, ஒரு குவியல் தரவுகளை வைத்துள்ளீர்கள். இங்குதான் உண்மையான வேலை தொடங்குகிறது—அந்த மூல எண்களை உண்மையில் அர்த்தமுள்ள ஒன்றாக மொழிபெயர்ப்பது. உங்கள் நெட்வொர்க்கின் ஆரோக்கியத்தைப் பற்றி தரவு ஒரு கதையைச் சொல்கிறது; அதை எப்படிப் படிப்பது என்பதை நீங்கள் கற்றுக்கொள்ள வேண்டும்.

உதாரணமாக, ஒரு traceroute இல் ரவுண்ட்-ட்ரிப் டைம் (RTT) இல் திடீர் அதிகரிப்பு ஒரு கிளாசிக் துப்பு. தாமதம் மூன்றாவது ஹாப் இல் அதிகரித்து, இறுதி வரை அதிகமாக இருந்தால், நீங்கள் உங்கள் சிக்கலைக் கண்டுபிடித்துவிட்டீர்கள்: அது மூன்றாவது ரூட்டர் அல்லது அதற்குப் பிறகு உள்ள இணைப்பு. ஆனால் கவனமாக இருங்கள். அந்த ஒற்றை ஹாப் மட்டுமே அதிக தாமதத்தைக் காட்டினால், இறுதி இலக்கு இன்னும் விரைவாக இருந்தால், அது உங்கள் சோதனை பயன்படுத்தும் குறிப்பிட்ட வகையான போக்குவரத்திற்கு முன்னுரிமை அளிக்காத ஒரு ரூட்டராக இருக்கலாம். இது ஒரு பொதுவான தவறான எச்சரிக்கை, இது உங்களை ஒரு முயல் குழிக்குள் தள்ளக்கூடும்.

ஜிட்டர் மற்றும் பாக்கெட் இழப்பை டிகோடிங் செய்தல்

சாதாரண RTT-ஐத் தாண்டிப் பார்ப்பதுதான் மிக முக்கியமான நுண்ணறிவுகளைக் கண்டறியும். அதிக ஜிட்டர், அதாவது சீரற்ற தாமதத்திற்கான ஒரு ஆடம்பரமான சொல், தொடர்ந்து அதிக தாமதத்தை விட மிகவும் சீர்குலைக்கும். இது குறிப்பாக நிகழ்நேர விஷயங்களுக்கு மிகவும் உண்மை.

உங்கள் முடிவுகள் சராசரி RTT 40ms என்று காட்டினால், ஆனால் குறைந்தபட்சம் 10ms ஆகவும் அதிகபட்சம் 150ms ஆகவும் இருந்தால், உங்கள் இணைப்பு நிலையற்றது. இந்த பெரிய மாறுபாடுதான் வீடியோ அழைப்புகளில் எரிச்சலூட்டும் தடுமாற்றங்களையும், ஆன்லைன் கேம்களில் கோபத்தை தூண்டும் லேக் ஸ்பைக்குகளையும் ஏற்படுத்துகிறது.

பேக்கெட் இழப்பு இன்னும் பெரிய சிவப்பு கொடி. 1% பேக்கெட் இழப்பு கூட TCP அடிப்படையிலான பயன்பாடுகளை முற்றிலும் முடக்கிவிடும், தரவை மீண்டும் மீண்டும் அனுப்பும்படி கட்டாயப்படுத்தி எல்லாவற்றையும் மெதுவாக்கும். உங்கள் சோதனை முடிவுகளைப் பார்க்கும்போது, அனுப்பப்பட்ட பேக்கெட்டுகளுக்கும் பெறப்பட்ட பேக்கெட்டுகளுக்கும் இடையே உள்ள எந்தவொரு உண்மையான வித்தியாசமும் உடனடியாக விசாரிக்கப்பட வேண்டும்.

மக்கள் செய்யும் மிகப்பெரிய தவறுகளில் ஒன்று, ஒரு சோதனை முழு கதையையும் சொல்கிறது என்று கருதுவதுதான். நெட்வொர்க் நிலைமைகள் தொடர்ந்து மாறிக்கொண்டே இருக்கின்றன. அதிகாலை 3 மணிக்கு நடத்தப்படும் ஒரு சோதனை, உச்ச வணிக நேரங்களில் மாலை 3 மணிக்கு நடத்தப்படும் சோதனையிலிருந்து முற்றிலும் மாறுபட்டதாக இருக்கும். உண்மையான செயல்திறன் அடிப்படையைப் பெறுவதற்கான ஒரே வழி, சீரான, மீண்டும் மீண்டும் சோதனை செய்வதுதான்.

பிரச்சனைகளை முன்கூட்டியே கண்டறிய, நெட்வொர்க் செயல்திறன் கண்காணிப்புக்கான பிரத்யேக கருவிகளைப் பார்ப்பது மதிப்பு. இது உங்கள் அணுகுமுறையை, விஷயங்கள் உடைந்தால் அவசரமாக சரிசெய்வதிலிருந்து, உங்கள் நெட்வொர்க்கை முன்கூட்டியே ஆரோக்கியமாக வைத்திருப்பதற்கு மாற்றுகிறது.

மிகவும் பொதுவான அளவீட்டு தவறுகள்

உலகின் சிறந்த கருவிகள் இருந்தாலும், சில எளிய தவறுகள் உங்கள் முடிவுகளை முற்றிலும் பயனற்றதாக்கலாம். நீங்கள் உண்மையில் நம்பக்கூடிய தரவை விரும்பினால், இந்த பொதுவான தவறுகளைத் தவிர்ப்பது கட்டாயமாகும்.

• Wi-Fi மூலம் சோதனை செய்தல்: உண்மையில், இதைச் செய்யாதீர்கள். வயர்லெஸ் இணைப்புகள் மிகவும் நிலையற்றவை, மைக்ரோவேவ்கள் முதல் உங்கள் அண்டை வீட்டின் ரூட்டர் வரை எல்லாவற்றிலிருந்தும் குறுக்கீடுகளுக்கு ஆளாகின்றன. எந்தவொரு தீவிர தாமத சோதனைக்கும், ஈதர்நெட் கேபிள் மூலம் இணைக்கவும். நிலையான, நம்பகமான அடிப்படையைப் பெறுவதற்கான ஒரே வழி இதுதான்.
• VPN ஓவர்ஹெட்டை மறந்துவிடுதல்: VPNகள் பாதுகாப்புக்கு சிறந்தவை, ஆனால் அவை உங்கள் டிராஃபிக்கின் பயணத்திற்கு ஒரு கூடுதல் நிறுத்தம் மற்றும் குறியாக்கத்தைச் சேர்க்கின்றன. இது எப்போதும் தாமதத்தை அதிகரிக்கும். ஒரு பயனரின் மெதுவான இணைப்பைக் கண்டறிய நீங்கள் முயற்சித்தால், உங்கள் முதல் கேள்விகளில் ஒன்று, "நீங்கள் VPN இல் இருக்கிறீர்களா?" என்பதாக இருக்க வேண்டும். அதனுடன் மற்றும் அது இல்லாமல் சோதனை செய்வது, அது எவ்வளவு தாமதத்தைச் சேர்க்கிறது என்பதை உங்களுக்குத் துல்லியமாகக் காட்டும்.
• உள்ளூர் நெட்வொர்க் நெரிசலை புறக்கணித்தல்: உங்கள் நெட்வொர்க்கில் வேறு யாராவது அனைத்து அலைவரிசையையும் பயன்படுத்தினால், உங்கள் சோதனை முடிவுகள் தவறாக இருக்கும். நீங்கள் சோதனை செய்யும்போது ஒரு சக ஊழியர் 4K வீடியோவை ஸ்ட்ரீமிங் செய்தாலோ அல்லது பெரிய கோப்புகளைப் பதிவிறக்கம் செய்தாலோ, உங்கள் தாமத எண்கள் அதிகமாக இருக்கும், மேலும் நீங்கள் இல்லாத ஒரு பிரச்சனையைத் தேடி அலைவீர்கள்.

மற்றொரு நுட்பமான ஆனால் முக்கியமான காரணி நீங்கள் தேர்ந்தெடுக்கும் கருவி. நாம் பார்த்தபடி, வெவ்வேறு பயன்பாடுகள் தாமதத்தை வெவ்வேறு வழிகளில் அளவிடுகின்றன. ஒப்பீட்டிற்கு நீங்கள் பயன்படுத்தும் கருவிகளில் எப்போதும் சீராக இருங்கள், மேலும் ஒவ்வொன்றும் உண்மையில் எதை அளவிடுகின்றன என்பதைப் புரிந்துகொள்ளுங்கள் - அது ஒரு எளிய ICMP எதிரொலியாக இருந்தாலும் அல்லது ஒரு சிக்கலான, பயன்பாட்டு-நிலை கோரிக்கையாக இருந்தாலும் சரி. மேலும் நினைவில் கொள்ளுங்கள், செயல்திறன் பல அடுக்குகளால் பாதிக்கப்படலாம்; உதாரணமாக, நீங்கள் வலை செயல்திறனை ஆராய்ந்தால், குக்கீ எடிட்டர் குரோம் நீட்டிப்பு பற்றிய எங்கள் வழிகாட்டி கிளையன்ட்-பக்க கூறுகள் எவ்வாறு ஒரு பங்கை வகிக்கின்றன என்பதைக் காட்டலாம்.

சரியான சூழலுடன் உங்கள் முடிவுகளை விளக்குவதன் மூலமும், இந்த பொதுவான தவறுகளைத் தவிர்ப்பதன் மூலமும், நீங்கள் வெறும் எண்களைச் சேகரிப்பதை விட முன்னேறுவீர்கள். உங்கள் நெட்வொர்க்கின் செயல்திறனுக்குப் பின்னால் உள்ள ஏன் என்பதைப் புரிந்துகொள்ளத் தொடங்குவீர்கள், மேலும் வேகமான, நம்பகமான அமைப்புகளை உருவாக்குவதற்கான திறவுகோல் அதுதான்.

நெட்வொர்க் தாமதம் பற்றிய பொதுவான கேள்விகள்

சரியான கருவிகள் இருந்தாலும், நெட்வொர்க் தாமதத்தை ஆராயத் தொடங்கும் போது சில பொதுவான கேள்விகள் எப்போதும் எழுகின்றன. உங்கள் முடிவுகளைப் புரிந்துகொள்ள உதவும் வகையில் நான் அடிக்கடி கேட்கும் சிலவற்றை இப்போது பார்ப்போம்.

உண்மையில் ஒரு "நல்ல" தாமத எண் என்ன?

இது கிளாசிக் "அது சார்ந்தது" என்ற கேள்வி, ஆனால் நாம் சில உறுதியான அளவுகோல்களை நிச்சயமாக அமைக்கலாம். ஒரு "நல்ல" தாமதம் நீங்கள் எதைச் சாதிக்க முயற்சிக்கிறீர்கள் என்பதைப் பொறுத்து முற்றிலும் தொடர்புடையது.

• சாதாரண வலை உலாவல்: நம்மில் பெரும்பாலானவர்களுக்கு, 100ms RTT க்கு கீழ் உள்ள எதுவும் சரியாக இருக்கும். பக்கங்கள் விரைவாக ஏற்றப்படும், மேலும் நீங்கள் எந்த உண்மையான தாமதத்தையும் கவனிக்க மாட்டீர்கள்.
• போட்டி ஆன்லைன் கேமிங்: இங்கு ஒவ்வொரு மில்லிசெகண்டும் முக்கியம். தீவிரமான விளையாட்டாளர்கள் மற்றும் உயர்-அதிர்வெண் வர்த்தகர்கள் 20ms க்கும் குறைவான தாமதத்தை எதிர்பார்க்கிறார்கள். இது வெற்றிக்கும் தோல்விக்கும் உள்ள வித்தியாசம்.
• வீடியோ அழைப்புகள் & VoIP: இங்கு, நிலைத்தன்மைதான் முக்கியம். அந்த துண்டு துண்டான, ஒத்திசைவற்ற உணர்வைத் தவிர்க்க அல்லது மோசமாக, அழைப்புகள் துண்டிக்கப்படுவதைத் தவிர்க்க, 150ms க்கும் குறைவான நிலையான தாமதம் மற்றும் குறைந்த ஜிட்டர் (30ms க்கும் குறைவானது) உங்களுக்குத் தேவை.

ஒரு பொது விதியாக, எனக்குத் தெரிந்த பெரும்பாலான நெட்வொர்க் வல்லுநர்கள் 50ms க்கும் குறைவான எதையும் குறைந்த தாமதமாக வகைப்படுத்துவார்கள். 50-150ms என்பது மிதமானது, மேலும் நீங்கள் 150ms ஐத் தாண்டும்போது, பெரும்பாலான ஊடாடும் பயன்பாடுகளில் இழுபறியை உணரத் தொடங்குவீர்கள்.

எனது பிங் மற்றும் உலாவி வேக சோதனை முடிவுகள் ஏன் ஒருபோதும் பொருந்தவில்லை?

இது ஒரு அருமையான கேள்வி மற்றும் ஒரு சூப்பர் பொதுவான குழப்பமான புள்ளி. ஒரு கட்டளை வரி ping மற்றும் ஒரு உலாவி அடிப்படையிலான வேக சோதனை ஆகியவை அடிப்படையில் வெவ்வேறு விஷயங்களை அளவிடும் வெவ்வேறு கருவிகள் என்பதால் இது நிகழ்கிறது.

முதலில், அவை கிட்டத்தட்ட நிச்சயமாக வெவ்வேறு சேவையகங்களுடன் பேசுகின்றன. நீங்கள் ஒரு டொமைனை ping செய்யும்போது, நீங்கள் ஒரு குறிப்பிட்ட இலக்கை அடைகிறீர்கள். மறுபுறம், ஒரு வலை வேக சோதனை, அதன் சொந்த நெட்வொர்க்கிலிருந்து புவியியல் ரீதியாக நெருக்கமான சேவையகத்தைக் கண்டறிந்து உங்களுக்கு சிறந்த-நிலை முடிவை வழங்க வடிவமைக்கப்பட்டுள்ளது.

நெறிமுறைகளும் முற்றிலும் வேறுபட்டவை. Ping ICMP எனப்படும் மிக இலகுரக நெறிமுறையைப் பயன்படுத்துகிறது. பெரும்பாலான உலாவி சோதனைகள் TCP வழியாக இயங்குகின்றன, இது ஒரு இணைப்பை நிறுவ ஒரு முழு அமைவு செயல்முறையை ("மூன்று வழி ஹேண்ட்ஷேக்") கோருகிறது. அந்த ஆரம்ப பரிமாற்றம் உண்மையான சோதனை தொடங்குவதற்கு முன்பே சிறிது நேரத்தைச் சேர்க்கிறது.

இறுதியாக, உலாவி சோதனைகள் பெரும்பாலும் தூய நெட்வொர்க் பயண நேரத்தை விட அதிகமாகவே உள்ளடக்கியுள்ளன. அவற்றின் "தாமதம்" எண் சேவையக செயலாக்க நேரம் அல்லது உங்கள் உலாவியில் உள்ள சிறிய தாமதங்கள் கூட இருக்கலாம், இது ஒரு மூல ICMP பிங்கை விட இறுதி எண்ணிக்கையை அதிகரிக்கலாம்.

எனது நெட்வொர்க் தாமதத்தை நான் உண்மையில் எவ்வாறு குறைக்க முடியும்?

தாமதத்தைக் குறைப்பது என்பது உங்கள் அலுவலகத்திலோ அல்லது இணையத்திலோ உள்ள தடைகளை வேட்டையாடி அகற்றுவதுதான்.

முதலில் பார்க்க வேண்டிய இடம் உங்கள் உடனடி சூழல். நீங்கள் செய்யக்கூடிய மிகச் சிறந்த மாற்றம் Wi-Fi இலிருந்து வயர்டு ஈதர்நெட் இணைப்புக்கு மாறுவதுதான். இது நிலைத்தன்மை மற்றும் வேகத்திற்கு ஒரு கேம்-சேஞ்சர். நீங்கள் Wi-Fi ஐப் பயன்படுத்த வேண்டியிருந்தால், உங்கள் ரூட்டருக்கு அருகில் சென்று 5GHz பேண்டில் செல்லுங்கள் - இது பொதுவாக நெரிசல் குறைவாக இருக்கும்.

உங்கள் உள்ளூர் நெட்வொர்க்கைத் தாண்டிப் பார்த்தால், சில சமயங்களில் ஒரு DNS மாற்றம் உதவும். வேகமான DNS சேவையகத்தைப் பயன்படுத்துவது, நீங்கள் ஒரு வலைத்தளத்தைப் பார்க்கும்போது ஆரம்ப இணைப்பு நேரத்திலிருந்து மில்லிசெகண்டுகளைக் குறைக்கலாம்.

நீங்கள் கட்டுப்படுத்தும் ஒரு சேவைக்கான அணுகலை மேம்படுத்த முயற்சிக்கிறீர்கள் என்றால், ஒரு உள்ளடக்க விநியோக நெட்வொர்க் (CDN) தான் பதில். இது உங்கள் உள்ளடக்கத்தின் நகல்களை உங்கள் பயனர்களுக்கு உடல் ரீதியாக நெருக்கமாக வைப்பதன் மூலம் செயல்படுகிறது. மேலும் நீங்கள் ஒரு VPN ஐப் பயன்படுத்துகிறீர்கள் என்றால், அதை அணைக்க முயற்சிக்கவும். அந்த கூடுதல் ஹாப் மற்றும் குறியாக்க அடுக்கு கிட்டத்தட்ட எப்போதும் தாமதத்தைச் சேர்க்கிறது.

கார்ப்பரேட் VPNகள் ஒரு ரவுண்ட்-ட்ரிப் நேரத்திற்கு 70ms வரை சேர்த்திருப்பதை நான் பார்த்திருக்கிறேன். இது ஒரு சிறந்த இணைப்பை எரிச்சலூட்டும் மெதுவான ஒன்றாக மாற்றும். நீங்கள் உண்மையில் எவ்வளவு செயல்திறன் இழப்பை சந்திக்கிறீர்கள் என்பதைப் பார்க்க எப்போதும் உங்கள் VPN உடன் மற்றும் அது இல்லாமல் சோதிக்கவும்.

தாமதம் மற்றும் அலைவரிசைக்கு இடையே உள்ள உண்மையான வித்தியாசம் என்ன?

இதை சரியாகப் புரிந்துகொள்வது நெட்வொர்க் செயல்திறனைப் புரிந்துகொள்வதற்கு அடிப்படையானது. அவற்றை குழப்புவது எளிது, ஆனால் அவை இரண்டு வெவ்வேறு விஷயங்களை அளவிடுகின்றன.

நான் எப்போதும் பயன்படுத்தும் ஒப்புமை இதுதான்: இதை ஒரு நெடுஞ்சாலையாக நினைத்துப் பாருங்கள்.

• அலைவரிசை என்பது நெடுஞ்சாலையில் எத்தனை பாதைகள் உள்ளன என்பதுதான். அதிக பாதைகள் என்றால் அதிக கார்கள் (தரவு) ஒரே நேரத்தில் பயணிக்க முடியும்.
• தாமதம் என்பது வேக வரம்பு. இது ஒரு ஒற்றை கார் (ஒரு தரவு பாக்கெட்) A இலிருந்து B க்கு எவ்வளவு வேகமாக செல்ல முடியும் என்பதை தீர்மானிக்கிறது.

நீங்கள் ஒரு பெரிய, பத்து-வழி நெடுஞ்சாலையை (அதிக அலைவரிசை) 20 mph வேக வரம்புடன் (அதிக தாமதம்) வைத்திருக்கலாம். நீங்கள் இறுதியில் ஒரு டன் தரவை நகர்த்தலாம், ஆனால் வீடியோ அழைப்பு போன்ற நிகழ்நேர விஷயங்கள் மிகவும் மெதுவாக இருக்கும். மறுபுறம், மிகக் குறைந்த தாமதம் கொண்ட ஒரு இணைப்பு நம்பமுடியாத அளவிற்கு வேகமாகவும் பதிலளிக்கக்கூடியதாகவும் உணர்கிறது, அதன் அலைவரிசை பெரியதாக இல்லாவிட்டாலும் கூட. ஒரு சிறந்த அனுபவத்திற்கு உங்களுக்கு இரண்டின் நல்ல சமநிலையும் தேவை.

---

உங்கள் தினசரி பணிப்பாய்வில் செயல்திறன் சோதனையை ஒரு தடையற்ற பகுதியாக மாற்றத் தயாரா? ShiftShift Extensions தொகுப்பு ஒரு சக்திவாய்ந்த வேக சோதனை, JSON வடிவமைப்பான் மற்றும் டஜன் கணக்கான பிற டெவலப்பர் கருவிகளை உங்கள் உலாவியில், ஒரு கட்டளையுடன் அணுகக்கூடியதாக வைக்கிறது. தாவல்களைக் கையாளுவதை நிறுத்திவிட்டு, புத்திசாலித்தனமாக வேலை செய்யத் தொடங்குங்கள். ShiftShift Extensions ஐ இலவசமாகப் பதிவிறக்கி, இன்று உங்கள் உற்பத்தித்திறனை மேம்படுத்துங்கள்.