Час витрачає на роботу
Команда не зависає і не чекає на те, щоб витратити час,
вона фактично виконує роботу, яка вимагає часу; Це, швидше за все, вимагає часу, додаючи кілька невеликих затримок у мережі. Але також може бути затримка з боку 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часи, це зробить це набагато швидше.
Справа не в тому, щоб "пінг" часів вашого Інтернет-провайдера; Час ping весь шлях до YouTube - це важливо - а можливо змінити неможливо.
Цікаво, що для наступного кроку, завантаження відео, вимоги до швидкої лінії прямо протилежні: затримка взагалі не актуальна, а пропускна здатність справді має значення.
Ще не втомився?
Хочете ще детальніше зрозуміти, на що насправді витрачається час?
Наступним кроком буде відстеження HTTP-з'єднання; Я б підозрював, що він може показувати набагато більше переходів, ніж два, наприклад, для переадресації. Ви можете використовувати wiresharkабо протокол HTTP-протоколу, що straceзаписує , або просто рахувати системні виклики для з'єднання або запису.
На сьогодні ми обидва заглянули досить глибоко у кролячу дірку.