時間は仕事をして過ごすことです
コマンドはハングしたり、時間の浪費を待ったりするものではなく、
実際には時間のかかる作業を行います。おそらく、複数の小さなネットワーク遅延を合計することで時間がかかります。しかし、YouTube側で遅延が発生していることも考えられます。
必要なHTMLをダウンロードするのにかかる時間です。
コマンドは、少なくとも2つの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
はい、1.5秒です。問題よりも高速ですが、それほど高速ではありません。しかし、それはどのように時間を費やしていますか？多分それはいくつかの隠された方法でビデオをダウンロードしてそれを破棄しますか？動画は360pで11分です。オプションなしでダウンロードするだけで約13秒から10倍かかります。
詳細オプションを使用して、詳しく調べる必要があります-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
ああ、 '[debug]'行が出力されるまでに多少の遅延があります。youtube-dlそれはそれ自身の構成設定のためにいくらかの時間を費やしているように見えます。それは1/4秒程度であり、私たちが求めている遅延ではありません。しかし、そこから学べることは、youtube-dl実装自体が遅い可能性があるということです。
メッセージの後、結果のURLが出力されるまで何も起こりません。したがって、私たちはまだ興味深い部分を見ていません。
オプション-gは、その半秘密のURLを見つけるという複雑な部分を実行して印刷するという意味で、ビデオのダウンロードを「シミュレート」することですが、最後に実際のダウンロードをスキップします。-sURLを出力しない同様のオプションがあり、それ以外は同様に見えます。ほぼ同じ時間がかかる場合、それは十分に類似していると仮定しましょう。それを確認する必要があります。
$ 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
OK、-sと同じ時間がかかる-gので、テストのために置き換えても問題ありません。
さらに興味深いのは、出力が増えたことです。そして、それは興味深いタイミングで印刷されます：行はお互いに同じような遅延で印刷されます。したがって、それらは実際に私たちが探している時間を費やしているアクションに関するものであるようです。
メッセージから、少なくとも2つのWebページがダウンロードされます。しかし、「ページ」という言葉は単一のHTTPリクエストと単一のHTMLドキュメントを意味しないと想定できます。
何を学びましたか？
重要な点は、プログラムの作業には実際には時間がかかることであり、何かを待ったり、ハングアップしたりすることはありません。
また、複数のステップで同様の時間がかかることもわかります。計算するものはそれほど多くないので、ネットワークの往復は何らかの形で加算されます。
つまり、接続のレイテンシはここでのみ重要です。接続のスループットは無関係です。
あなたがインターネット接続をより高速にしてデータを2倍の速度で転送できるようにするなら-それはまったく役に立たないでしょう。しかし、より良いping時間を得ることができれば、それはそれをはるかに速くします。
ただし、インターネットサービスプロバイダーに「ping」する時間ではありません。YouTubeへのping時間は重要です。変更することはできません。
興味深いことに、次のステップであるビデオのダウンロードでは、高速回線の要件は正反対です。遅延はまったく関係なく、スループットが本当に重要です。
まだ疲れていませんか？
時間が本当に実際に費やされているものを理解するためにさらに詳細が必要ですか？
次のステップは、HTTP接続をトレースすることです。たとえば、リダイレクトの場合、2回よりもはるかに多くのラウンドトリップが表示されるのではないかと思います。wireshark、またはロギングHTTPプロキシを使用するか、strace接続または書き込みのシステムコールをカウントするだけです。
今日、私たちは2人ともネットワークのうさぎの穴を十分に調べました。