Le temps est consacré au travail
La commande ne se bloque pas ou n'attend pas que quelque chose perde du temps,
elle fait un travail qui prend du temps; Cela prend très probablement du temps en additionnant plusieurs petits retards réseau. Mais il se pourrait aussi qu'il y ait des retards du côté youtube, qui s'additionnent.
Qu'il suffit du temps nécessaire pour télécharger le code HTML nécessaire;
La commande doit effectuer au moins deux requêtes HTTP, l'une après l'autre, et probablement plus.
Donc, si quelque chose est lent, il est déjà multiplié par le nombre de demandes.
Pour moi, cela prend 1,5 seconde sur une ligne très rapide - ce n'est pas si loin de 8 secondes.
Comment le découvrir
Je vais montrer les commandes que j'ai utilisées pour découvrir:
Pour rendre les exemples plus ordonnés, nous utilisons une variable pour l'URL:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
Nous voulons mesurer la durée des commandes; L'utilisation de la commande timedoit prendre soin de ne pas mélanger la commande et le shell intégré. Nous utilisons une petite fonction pour raccourcir les lignes:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
Votre commande écrit l'URL du fichier vidéo (tronquée à 80 colonnes):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Mesurons le temps nécessaire à l'exécution sur mon ordinateur:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
D'accord, une seconde et demie. Plus rapide que dans la question, mais pas beaucoup plus vite. Mais comment passe-t-il le temps? Peut-être qu'il télécharge la vidéo d'une manière cachée et la rejette? La vidéo est de 11min en 360p. Le télécharger sans aucune option prend environ 13 secondes, soit dix fois plus.
Besoin de regarder de plus près, avec l'option détaillée -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, il y a un certain délai avant que les lignes «[debug]» soient imprimées. On dirait qu'il youtube-dlpasse du temps pour sa propre configuration. C'est un quart de seconde environ, pas le délai que nous recherchons. Mais ce que nous pouvons en tirer, c'est que la youtube-dlmise en œuvre elle-même peut être lente.
Après les messages, rien ne se passe jusqu'à ce que l'URL du résultat soit imprimée. Nous ne voyons donc toujours pas la partie intéressante.
L'option -gconsiste à «simuler» le téléchargement de la vidéo dans le sens où elle fait la partie compliquée de la découverte de cette URL semi-secrète, l'imprime, puis ignore le téléchargement réel à la fin. Il existe une option similaire -squi ne génère pas l'URL et semble similaire dans le cas contraire. Supposons qu'il soit suffisamment similaire s'il prend environ le même temps; Nous devons vérifier cela.
$ 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, -sprend le même temps que -g, donc c'est ok de les remplacer pour les tests.
Plus intéressant, c'est que nous avons obtenu plus de sortie maintenant. Et il est imprimé avec un timing intéressant: les lignes sont imprimées avec un délai similaire les unes aux autres, il semble donc qu'elles concernent les actions qui prennent réellement le temps que nous recherchons.
À partir des messages, au moins deux pages Web sont téléchargées. Mais nous pouvons supposer que le mot "page" ne signifiera pas une seule requête HTTP et un seul document HTML.
Qu'avons-nous appris?
Le point principal est que le travail du programme prend en fait du temps, il n'attend pas quelque chose ou ne pend pas.
En outre, nous voyons plusieurs étapes nécessitant des délais similaires. Il n'y a pas grand-chose à calculer, c'est donc en quelque sorte des allers-retours sur le réseau.
Cela signifie que la latence de notre connexion n'est importante qu'ici. Le débit de la connexion est tout simplement hors de propos.
Si vous accélérez votre connexion Internet afin de pouvoir transférer des données à double vitesse - cela n'aiderait pas du tout. Mais si vous pouvez obtenir de meilleurs pingtemps, cela le rendra beaucoup plus rapide.
Il ne s'agit pas de «cingler» les temps à votre fournisseur de services Internet, cependant; Le temps de ping jusqu'à YouTube, c'est ce qui compte - et peut-être pas possible de changer.
Fait intéressant, pour l'étape suivante, le téléchargement d'une vidéo, les exigences pour une ligne rapide sont exactement le contraire: la latence n'est pas du tout pertinente et le débit est vraiment important.
Pas encore fatigué?
Vous voulez encore plus de détails pour comprendre à quoi vous consacrez vraiment le temps?
La prochaine étape serait de tracer la connexion HTTP; Je soupçonne qu'il peut afficher beaucoup plus d'aller-retour que deux, pour les redirections par exemple. Vous pouvez utiliser wireshark, ou un proxy HTTP de journalisation, ou stracesimplement compter les appels système pour la connexion ou l'écriture.
Pour aujourd'hui, nous avons tous deux regardé assez profondément dans le trou du lapin du réseautage.