काम करने में समय व्यतीत होता है
आदेश लटका या कुछ बर्बाद करने के लिए इंतजार नहीं करता है,
यह वास्तव में वह काम करता है जिसमें समय लगता है; यह संभवतः कई छोटे नेटवर्क देरी को जोड़कर समय लेता है। लेकिन यह भी हो सकता है कि यूट्यूब की तरफ से देरी हो, जो जोड़ दें।
यह केवल HTML को डाउनलोड करने के लिए आवश्यक समय लगता है;
कमांड को कम से कम दो HTTP अनुरोध करने की ज़रूरत है, एक के बाद एक, और शायद अधिक।
इसलिए यदि कुछ भी धीमा है, तो यह पहले से ही अनुरोधों की संख्या से कई गुना अधिक है।
मेरे लिए यह बहुत तेज़ लाइन पर 1.5 सेकंड लेता है - जो कि 8 सेकंड से ज्यादा दूर नहीं है।
कैसे पता करें
मैं उन कमांड्स को दिखाऊँगा जिनका उपयोग मैंने किया था:
उदाहरणों को अधिक स्पष्ट बनाने के लिए, हम URL के लिए एक चर का उपयोग करते हैं:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
हम आदेशों की अवधि को मापना चाहते हैं; कमांड का उपयोग timeकरने के लिए कमांड और शेल बिलिन का मिश्रण न करने की देखभाल करने की आवश्यकता है। हम लाइनों को छोटा करने के लिए एक छोटे से फ़ंक्शन का उपयोग करते हैं:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
आपकी कमांड वीडियो फ़ाइल के URL को लिखती है (80 स्तंभों में विभाजित):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
आइए मेरे कंप्यूटर पर चलने के समय को मापें:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
ठीक है, डेढ़ सेकंड। प्रश्न की तुलना में तेज़, लेकिन उतना तेज़ नहीं। लेकिन यह समय कैसे बिता रहा है? हो सकता है कि यह वीडियो को कुछ छिपे तरीके से डाउनलोड करता है और इसे त्याग देता है? वीडियो 360p में 11min है। बस इसे बिना किसी विकल्प के डाउनलोड करने में लगभग 13 - दस गुना अधिक समय लगता है।
क्रिया विकल्प के साथ, एक करीब से देखने की आवश्यकता है -v:
$ t youtube-dl -v -g "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-g', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?sparams=id%2Cinitcwn
Time: 1.40s
ओह, '[डिबग]' लाइनें छपने से पहले कुछ देरी हो रही है। ऐसा लगता है कि youtube-dlयह कॉन्फ़िगरेशन कॉन्फ़िगरेशन के लिए कुछ समय बिताता है। यह एक-दूसरे का एक चौथाई हिस्सा है, न कि वह विलंब जिसकी हम तलाश कर रहे हैं। लेकिन हम इससे क्या सीख सकते हैं कि youtube-dlकार्यान्वयन स्वयं धीमा हो सकता है।
संदेशों के बाद, परिणाम URL प्रिंट होने तक कुछ नहीं होता है। इसलिए हम अभी भी दिलचस्प हिस्सा नहीं देखते हैं।
विकल्प -gइस अर्थ में वीडियो डाउनलोड को "अनुकरण" करने के लिए है कि यह उस अर्ध-गुप्त URL को खोजने का जटिल हिस्सा करता है, इसे प्रिंट करता है, लेकिन फिर अंत में वास्तविक डाउनलोड को छोड़ देता है। एक समान विकल्प है -sजो URL को आउटपुट नहीं करता है, और अन्यथा समान लगता है। चलो मान लें कि यह समान है यदि यह एक ही समय के बारे में लेता है; हमें इसकी जाँच करने की आवश्यकता है।
$ t youtube-dl -v -s "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-s', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
[youtube] Setting language
[youtube] k4JGSAmu4lg: Downloading webpage
[youtube] k4JGSAmu4lg: Downloading video info webpage
[youtube] k4JGSAmu4lg: Extracting video information
Time: 1.45s
ठीक है, के -sरूप में एक ही समय लगता है -g, इसलिए उन्हें परीक्षण के लिए प्रतिस्थापित करना ठीक है।
अधिक दिलचस्प यह है कि हमें अब अधिक आउटपुट मिला है। और यह एक दिलचस्प समय के साथ मुद्रित होता है: लाइनें एक-दूसरे के साथ समान देरी से मुद्रित होती हैं, इसलिए ऐसा लगता है कि वे उन कार्यों के बारे में हैं जो वास्तव में उस समय के लिए हैं जो हम खोज रहे हैं।
संदेशों से, कम से कम दो वेब पेज डाउनलोड किए जाते हैं। लेकिन हम यह मान सकते हैं कि शब्द "पृष्ठ" का अर्थ एक HTTP अनुरोध और एक HTML दस्तावेज़ नहीं होगा।
हमने क्या सीखा?
मुख्य बिंदु यह है कि कार्यक्रम का काम वास्तव में समय लेता है, यह किसी चीज की प्रतीक्षा नहीं कर रहा है, न ही लटका हुआ है।
साथ ही, हम कई चरणों को समान मात्रा में लेते हुए देखते हैं। गणना करने के लिए बहुत कुछ नहीं है, इसलिए यह नेटवर्क राउंडट्रिप्स को किसी तरह से जोड़ रहा है।
इसका मतलब है, हमारे कनेक्शन की विलंबता केवल यहाँ महत्वपूर्ण है। कनेक्शन का थ्रूपुट सिर्फ अप्रासंगिक है।
यदि आप अपने इंटरनेट कनेक्शन को तेज़ करेंगे तो यह दोगुनी गति से डेटा स्थानांतरित कर सकता है - जो बिल्कुल भी मदद नहीं करेगा। लेकिन अगर आप बेहतर pingसमय प्राप्त कर सकते हैं , तो यह बहुत तेज कर देगा।
यह आपके इंटरनेट सेवा प्रदाता के लिए 'पिंग' समय के बारे में नहीं है, हालांकि; YouTube के लिए सभी तरह से पिंग का समय मायने रखता है - और बदलना संभव नहीं हो सकता है।
दिलचस्प बात यह है कि अगले चरण के लिए, एक वीडियो डाउनलोड करना, एक तेज रेखा की आवश्यकताएं इसके बिल्कुल विपरीत हैं: विलंबता बिल्कुल भी प्रासंगिक नहीं है, और थ्रूपुट वास्तव में मायने रखता है।
अभी तक नहीं थके?
यह समझने के लिए कि क्या वास्तव में समय व्यतीत हो रहा है, अभी और अधिक विवरण चाहते हैं?
अगला कदम HTTP कनेक्शन को ट्रेस करना होगा; मुझे संदेह होगा कि यह उदाहरण के लिए पुनर्निर्देश के लिए दो की तुलना में कई अधिक राउंडट्रिप्स दिखा सकता है। आप wiresharkHTTP प्रॉक्सी का उपयोग कर सकते हैं , या लॉगिंग straceया लिखने के लिए सिस्टम कॉल की गणना कर सकते हैं।
आज के लिए, हम दोनों नेटवर्किंग के खरगोश छेद में काफी गहरे दिख रहे हैं।