Il tempo è dedicato al lavoro
Il comando non si blocca o aspetta qualcosa che perde tempo,
in realtà funziona che richiede tempo; Molto probabilmente ci vuole tempo sommando più piccoli ritardi di rete. Ma potrebbe anche essere che ci siano ritardi sul lato YouTube, che si sommano.
Che è solo il tempo necessario per scaricare l'HTML necessario;
Il comando deve effettuare almeno due richieste HTTP, una dopo l'altra e probabilmente di più.
Quindi, se qualcosa è lento, viene moltiplicato per il numero di richieste già.
Per me ci vogliono 1,5 secondi su una linea molto veloce - che non è poi così lontana da 8 secondi.
Come scoprirlo
Mostrerò i comandi che ho usato per scoprire:
Per rendere gli esempi più ordinati, utilizziamo una variabile per l'URL:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
Vogliamo misurare la durata dei comandi; L'uso del comando timedeve fare attenzione a non confondere il comando e la shell incorporata. Usiamo una piccola funzione per accorciare le linee:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
Il tuo comando scrive l'URL del file video (troncato a 80 colonne):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Misuriamo il tempo necessario per l'esecuzione sul mio computer:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
Ok, un secondo e mezzo. Più veloce della domanda, ma non molto più veloce. Ma come passa il tempo? Forse scarica il video in qualche modo nascosto e lo scarta? Il video dura 11 minuti a 360p. Il solo download senza opzioni richiede circa 13 secondi, dieci volte di più.
È necessario dare un'occhiata più da vicino, con l'opzione dettagliata -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
Oh, c'è qualche ritardo prima che le righe '[debug]' vengano stampate. Sembra che youtube-dlpassi del tempo per la propria configurazione. È circa un quarto di secondo, non il ritardo che stiamo cercando. Ma da ciò che possiamo imparare è che l' youtube-dlimplementazione stessa potrebbe essere lenta.
Dopo i messaggi, non accade nulla fino alla stampa dell'URL del risultato. Quindi non vediamo ancora la parte interessante.
L'opzione -gè "simulare" il download del video, nel senso che fa la parte complicata di scoprire quell'URL semi-segreto, lo stampa, ma alla fine salta il download effettivo. Esiste un'opzione simile -sche non genera l'URL e sembra simile in caso contrario. Supponiamo che sia abbastanza simile se impiega più o meno lo stesso tempo; Dobbiamo verificarlo.
$ 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, -simpiega lo stesso tempo -g, quindi va bene sostituirli per i test.
Più interessante è che ora abbiamo ottenuto più output. Ed è stampato con un tempismo interessante: le linee vengono stampate con un ritardo simile l'una all'altra, quindi sembra che riguardino le azioni che stanno effettivamente prendendo il tempo che cerchiamo.
Dai messaggi, vengono scaricate almeno due pagine Web. Ma possiamo presumere che la parola "pagina" non significherà una singola richiesta HTTP e un singolo documento HTML.
Che cosa abbiamo imparato?
Il punto principale è che il lavoro del programma in realtà richiede tempo, non è in attesa di qualcosa o impiccagione.
Inoltre, vediamo più passaggi che richiedono quantità di tempo simili. Non c'è molto da calcolare, quindi si tratta di roundtrip di rete in qualche modo, sommando.
Ciò significa che la latenza della nostra connessione è importante solo qui. Il throughput della connessione è semplicemente irrilevante.
Se rendessi la tua connessione Internet più veloce in modo che possa trasferire i dati a doppia velocità, ciò non aiuterebbe affatto. Ma se riesci a ottenere pingtempi migliori , sarà molto più veloce.
Tuttavia, non si tratta di "ping" volte al tuo provider di servizi Internet; Il tempo di ping fino a YouTube è importante e potrebbe non essere possibile modificarlo.
È interessante notare che per il passaggio successivo, il download di un video, i requisiti per una linea veloce sono esattamente l'opposto: la latenza non è affatto rilevante e la velocità effettiva conta davvero.
Non sei ancora stanco?
Desideri ulteriori dettagli per capire in che tempo passa davvero?
Il prossimo passo sarebbe quello di tracciare la connessione HTTP; Sospetto che possa mostrare molti più roundtrip di due, ad esempio per i reindirizzamenti. È possibile utilizzare wiresharkun proxy HTTP di registrazione o stracesemplicemente contare le chiamate di sistema per la connessione o la scrittura.
Per oggi, abbiamo entrambi guardato abbastanza in profondità nella tana del coniglio della rete.