Время тратить на работу
Команда не зависает и не ждет, что что-то напрасно тратит время,
она действительно работает, что требует времени; Скорее всего, это займет некоторое время, сложив несколько небольших сетевых задержек. Но также может быть, что есть задержки на стороне YouTube, которые складываются.
Это просто время, необходимое для загрузки необходимого 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
Хорошо, полторы секунды. Быстрее, чем в вопросе, но не намного быстрее. Но как он проводит время? Может быть, он скачивает видео каким-то скрытым способом и удаляет его? Видео 11 минут в 360p. Простая загрузка без параметров занимает около 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
О, есть некоторая задержка, прежде чем строки '[debug]' будут напечатаны. Похоже, 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-соединения; Я подозреваю, что он может показать гораздо больше циклических переходов, чем два, например, для перенаправлений. Вы можете использовать wiresharkили протокол HTTP-прокси, или straceпросто подсчитать системные вызовы для подключения или записи.
На сегодняшний день мы оба достаточно глубоко заглянули в кроличью нору сетей.