आपका डाउनलोड तेज़ है, तो फिर हर क्लिक धीमा क्यों लगता है?

बड़ी फ़ाइल तेज़ी से डाउनलोड करना और फिर हर क्लिक को धीमा महसूस करना कोई विरोधाभास नहीं है। क्षमता बताती है कि प्रति सेकंड कितना आगे बढ़ सकता है; राउंड-ट्रिप समय बताता है कि कुछ उपयोगी होने से पहले एक अदला-बदली में कितना समय लगता है। पहले को सुधारने से दूसरे के लिए कुछ नहीं होता, और दूसरा ही वह चीज़ है जो व्यक्ति टाइप करते, क्लिक करते या बोलते समय नोटिस करता है। शिकायत को मापें, कनेक्शन को नहीं।

तेज़ फ़ाइल, धीमा क्लिक: दो अलग आँकड़े

बड़े पैमाने का ट्रांसफ़र डेटा को लगातार गति में रखता है, इसलिए यह स्वस्थ दर बता सकता है भले ही हर अलग अनुरोध इंतज़ार कर रहा हो। कई बेंचमार्क एक साथ कई कनेक्शन भी खोलते हैं, जिससे कुल आँकड़ा बढ़ जाता है जबकि एक अनुरोध धीमा ही रहता है। दोनों नतीजे मेल खाते हैं, और देरी की शिकायत करने वाले उपयोगकर्ता को ऊँचा आँकड़ा बताना भरोसा खोने का तरीका है।

पेज लोड होना छोटी अदला-बदलियों की एक श्रृंखला है: नाम हल करना, कनेक्शन स्थापित करना, एक अनुरोध, एक जवाब और फिर निर्भर अनुरोध। हर चरण फिर से राउंड-ट्रिप चुकाता है, इसलिए ज़्यादा देरी वाला रास्ता भरपूर क्षमता होने पर भी धीमा लगता है।

टनल अपनी यात्रा और प्रोसेसिंग जोड़ता है, और नक्शे के लेबल से ज़्यादा रास्ता मायने रखता है। एक ही देश के दो एग्रेसों के एक गंतव्य तक रास्ते बहुत अलग हो सकते हैं। बीस मिलीसेकंड का अंतर एक पेज का एहसास बदलने के लिए काफ़ी है, हालाँकि यह थ्रूपुट के आँकड़े को मुश्किल से हिलाता है। इसीलिए एग्रेस चुनाव झंडे के आइकन के बजाय विलंबता के नमूने का पालन करना चाहिए।

शिकायत को मापें, कनेक्शन को नहीं

वह माप चुनें जो उपयोगकर्ता के कहे वाक्य से मेल खाता हो। धीमे डाउनलोड को सही दिशा में टिकाऊ दर चाहिए; लेटती कॉल को उस ऐप के अपने आँकड़े चाहिए; धीमे शुरू होने वाले पेज को नाम हल करने और स्थापित होने के समय चाहिए।

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 लगे जबकि थ्रूपुट ठीक था" एक माप है, और यह सीधे देरी की ओर इशारा करता है, क्षमता की ओर नहीं।