तुमचा डाउनलोड वेगवान आहे, मग प्रत्येक क्लिक हळू का वाटते?

मोठी फाईल वेगाने डाउनलोड करून नंतर प्रत्येक क्लिक हळू वाटणे हा विरोधाभास नाही। क्षमता सांगते की प्रति सेकंद किती हलू शकते; राउंड-ट्रिप वेळ सांगते की काही उपयुक्त घडण्यापूर्वी देवाणघेवाण किती काळ घेते। पहिली सुधारल्याने दुसऱ्यासाठी काहीही होत नाही, आणि दुसरी म्हणजे व्यक्ती टाइप करताना, क्लिक करताना किंवा बोलताना जे लक्षात घेते। तक्रार मोजा, कनेक्शन नाही।

वेगवान फाईल, हळू क्लिक: दोन वेगळे आकडे

मोठ्या प्रमाणातील हस्तांतरण डेटा सतत गतीत ठेवते, म्हणून प्रत्येक वैयक्तिक विनंती वाट पाहत असली तरी ते निरोगी दर नोंदवू शकते। अनेक बेंचमार्क एकाच वेळी अनेक कनेक्शन उघडतात, त्यामुळे एक विनंती हळू राहिली तरी एकूण आकडा वाढतो। दोन्ही निकाल सुसंगत आहेत, आणि विलंबाची तक्रार करणाऱ्या वापरकर्त्याला मोठा आकडा सांगणे हा विश्वास गमावण्याचा मार्ग आहे।

पृष्ठ लोड होणे म्हणजे लहान देवाणघेवाणींची साखळी: नाव निराकरण, कनेक्शन स्थापना, एक विनंती, एक प्रतिसाद आणि नंतर अवलंबून विनंत्या। प्रत्येक पायरी पुन्हा राउंड-ट्रिप भरते, म्हणून जास्त विलंबाचा मार्ग भरपूर क्षमता असूनही हळू वाटतो।

टनेल स्वतःचा प्रवास आणि प्रक्रिया जोडते, आणि नकाशावरील लेबलपेक्षा मार्ग जास्त महत्त्वाचा आहे। एकाच देशातील दोन एग्रेसचे एका गंतव्याकडेचे मार्ग खूप वेगळे असू शकतात। वीस मिलिसेकंदांचा फरक पृष्ठाची भावना बदलण्यासाठी पुरतो, तरी थ्रूपुटचा आकडा जेमतेम हलवतो। म्हणून एग्रेसची निवड ध्वजाच्या चिन्हापेक्षा लेटन्सीच्या नमुन्याचे अनुसरण करावी।

तक्रार मोजा, कनेक्शन नाही

वापरकर्त्याने म्हटलेल्या वाक्याशी जुळणारे माप निवडा। हळू डाउनलोडला योग्य दिशेने टिकाऊ दर हवा; उशिरा होणाऱ्या कॉलला त्या ॲपची स्वतःची आकडेवारी हवी; हळू सुरू होणाऱ्या पृष्ठाला नाव निराकरण आणि स्थापनेचे वेळ हवे।

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

पहिला आदेश अंदाज करण्यायोग्य प्रतिसाद देणाऱ्या होस्टकडे राउंड-ट्रिप नमुना देतो, दुसरा एका कनेक्शनसाठी पहिल्या बाइटपर्यंतचा वेळ आणि टिकाऊ दर सांगतो, आणि तिसरा चार समांतर प्रवाहांसह एकूण थ्रूपुट मोजतो। ते दिवसाच्या त्याच वेळी त्याच गंतव्याविरुद्ध चालवा, कारण सकाळच्या नमुन्याची संध्याकाळच्या नमुन्याशी तुलना माप नाही, कथा तयार करते।

एग्रेसची तुलना करताना गंतव्य स्थिर ठेवा। सर्व्हर आणि टनेल दोन्ही बदलल्याने एक चल दोन होतो, आणि निकाल कोणते महत्त्वाचे होते हे सांगू शकत नाही। प्रत्येक एग्रेस कमीत कमी तीन वेळा चालवा, कारण एकटा नमुना अनेकदा राउटिंग बदलात किंवा गोंगाटाच्या एका मिनिटात पडतो। सर्वोत्तम प्रकरणापेक्षा मध्यक अधिक उपयुक्त आहे।

ICMP ला उत्तर नाही, सुगावा माना। प्रतिसाद देणारा होस्ट तुमचे ॲप वापरते त्या मार्गापेक्षा वेगळ्या मार्गाने इको विनंत्या हाताळू शकतो, आणि एक हरवलेला प्रतिसाद प्रत्येक ॲप पॅकेट गमावत आहे याचा पुरावा नाही।

लोडखालील विलंब ही रांगेची समस्या आहे

लोकांना सर्वात जास्त गोंधळात टाकणारा नमुना म्हणजे निष्क्रिय असताना चांगले वाटणारे आणि बॅकअप दरम्यान निरुपयोगी होणारे कनेक्शन। ती रांग आहे, क्षमता नाही। भरलेली अपलिंक इतर प्रत्येक पॅकेटसमोर बफर तयार करते, म्हणून की-दाब अपलोडच्या एका भागामागे वाट पाहतो।

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

पहिला आदेश पार्श्वभूमीत विलंबाचे नमुने घेतो तर दुसरा विरुद्ध दिशा भरतो। हस्तांतरणादरम्यान ping वेळा उडी मारल्या आणि नंतर सावरल्या तर तुम्ही राउटिंग दोष शोधला नाही, तर bufferbloat पुन्हा निर्माण केला आहे। उपाय सहसा रांग व्यवस्थापनाची सेटिंग, कमी पार्श्वभूमी दर, किंवा मोठे हस्तांतरण परस्परसंवादी मार्गावरून दूर करणे हा आहे।

ऐच्छिक पार्श्वभूमी रहदारी कमी करणे एग्रेस देश बदलण्यापेक्षा अनेकदा जास्त मदत करते। ते स्वस्तही आहे, उलटवता येते आणि एका मिनिटात तपासता येते। रांग सांभाळता येत नसेल तर मोठे अपलोड कामाच्या वेळेबाहेर नियोजित करा, आणि दिवसा चालवावे लागल्यास त्यांचा दर मर्यादित करा। राउटर समर्थन देत असेल तर रांग व्यवस्थापनाची सेटिंग हा चांगला उपाय आहे।

एक गोष्ट बदला आणि समानाची समानाशी तुलना करा

जास्त निष्क्रिय विलंबासाठी गंतव्य स्थिर ठेवून एग्रेसची तुलना करा, नंतर सर्वोत्तम उमेदवारासाठी मार्गांची तुलना करा। कमी स्थिर थ्रूपुटसाठी त्याऐवजी क्षमता, सर्व्हर लोड आणि क्लायंट प्रक्रिया पहा, कारण त्या वेगळ्या मर्यादा आहेत।

तुम्ही काय मोजले, कोणत्या गंतव्याविरुद्ध, कोणत्या वेळी आणि कोणत्या सेटिंगसह ते लिहा। त्या चार तथ्यांशिवाय तुलना पुन्हा करता येत नाही, आणि पुढील व्यक्ती शून्यापासून सुरुवात करेल।

मग तिकिटातील दाव्याशी साधन जुळवा। "हळू इंटरनेट" हे माप नाही; "या होस्टपर्यंत पहिल्या बाइटला 900 ms लागले तर थ्रूपुट चांगले होते" हे माप आहे, आणि ते थेट क्षमतेकडे नाही, विलंबाकडे निर्देश करते।