C'est bien mieux que de pousser wget dans l'arrière-plan à l'aide de & o -b vous pouvez utiliser xargs au même effet, et mieux.
L'avantage est que xargs volonté se synchroniser correctement sans travail supplémentaire. Cela signifie que vous pouvez accéder en toute sécurité aux fichiers téléchargés (en supposant qu'aucune erreur ne se produise). Tous les téléchargements seront terminés (ou auront échoué) une fois que xargs sort, et le code de sortie permet de savoir si tout s'est bien passé. Cette solution est de loin préférable à l'attente laborieuse avec sleep et en testant l'achèvement manuellement.
En supposant que URL_LIST est une variable contenant toutes les URL (peut être construite avec une boucle dans l'exemple de l'OP, mais peut aussi être une liste générée manuellement), en exécutant ceci :
echo $URL_LIST | xargs -n 1 -P 8 wget -q
passera un argument à la fois ( -n 1 ) à wget et exécutent au maximum 8 wget à la fois ( -P 8 ). xarg revient après la fin du dernier processus créé, ce qui est exactement ce que nous voulions savoir. Aucune astuce supplémentaire n'est nécessaire.
Le "nombre magique" de 8 téléchargements parallèles que j'ai choisi n'est pas figé, mais il s'agit probablement d'un bon compromis. Deux facteurs permettent de "maximiser" une série de téléchargements :
La première consiste à remplir "le câble", c'est-à-dire à utiliser la largeur de bande disponible. Dans des conditions "normales" (le serveur a plus de bande passante que le client), c'est déjà le cas pour un ou deux téléchargements au maximum. Le fait d'ajouter des connexions au problème ne fera qu'entraîner l'abandon de paquets et la mise en œuvre du contrôle de congestion TCP. N avec des téléchargements asymptotiquement 1/N de bande passante chacun, pour le même effet net (moins les paquets abandonnés, moins la récupération de la taille de la fenêtre). L'abandon de paquets est une chose normale dans un réseau IP, c'est ainsi que le contrôle de la congestion est censé fonctionner (même avec une seule connexion), et normalement l'impact est pratiquement nul. Cependant, le fait d'avoir un nombre déraisonnablement élevé de connexions amplifie cet effet, de sorte qu'il peut devenir perceptible. Dans tous les cas, cela ne rend rien plus rapide.
Le deuxième facteur est l'établissement de la connexion et le traitement des demandes. Ici, le fait d'avoir quelques connexions supplémentaires en vol aide vraiment . Le problème auquel on est confronté est la latence de deux allers-retours (typiquement 20-40 ms dans la même zone géographique, 200-300 ms entre continents) plus les quelques 1-2 millisecondes dont le serveur a besoin pour traiter la demande et envoyer une réponse à la socket. Ce n'est pas beaucoup de temps en soi mais multiplié par quelques centaines/milliers de demandes, il s'additionne rapidement.
Le fait d'avoir entre une demi-douzaine et une douzaine de demandes en vol masque en grande partie ou totalement cette latence (elle est toujours présente, mais comme elle se chevauche, elle ne s'additionne pas !) En même temps, le fait de n'avoir que quelques connexions simultanées n'a pas d'effets négatifs, tels qu'une congestion excessive ou l'obligation pour un serveur d'ouvrir de nouveaux processus.
