Намного предпочтительнее отодвигать wget в фон с помощью & или -b, вы можете использовать xargs с тем же эффектом, но лучше.
Преимущество в том, что xargs будет правильно синхронизироваться без дополнительных усилий. Это означает, что вы можете безопасно получить доступ к загруженным файлам (при условии, что ошибок не произойдет). Все загрузки будут завершены (или завершены неудачно) после xargs выхода, и по коду выхода вы узнаете, все ли прошло успешно. Это предпочтительнее, чем ожидание с sleep и тестирование завершения вручную.
Предполагая, что URL_LIST - это переменная, содержащая все URL-адреса (может быть построена с помощью цикла в примере OP, но также может быть вручную сгенерированным списком), запустите это:
echo $URL_LIST | xargs -n 1 -P 8 wget -q
будет передавать один аргумент (-n 1) в wget и выполнять не более 8 параллельных wget процессов за раз (-P 8). xarg возвращается после завершения последнего порожденного процесса, и это именно то, что мы хотели знать. Никаких дополнительных уловок.
Выбранное мною «магическое число» 8 параллельных загрузок не высечено на камне, но, вероятно, это хороший компромисс. Есть два фактора в "максимизации" серии загрузок:
Один из них - заполнение «кабеля», то есть использование доступной полосы пропускания. Предполагая «нормальные» условия (сервер имеет большую пропускную способность, чем клиент), это уже имеет место при одной или максимум двух загрузках. Добавление большего количества подключений к проблеме приведет только к отбрасыванию пакетов и включению контроля перегрузки TCP, а также к N загрузкам с асимптотической пропускной способностью 1 / N каждая с тем же чистым эффектом. (минус отброшенные пакеты, минус восстановление размера окна). Отбрасывание пакетов - нормальное явление в IP-сети, именно так должен работать контроль перегрузки (даже при одном подключении), и обычно влияние практически нулевое. Однако наличие неоправданно большого количества подключений усиливает этот эффект, поэтому он может стать заметным. В любом случае быстрее ничего не делает.
Второй фактор - это установление соединения и обработка запроса. Здесь действительно помогает наличие нескольких дополнительных стыковок в полете. Проблема, с которой приходится сталкиваться, - это задержка двух циклов приема-передачи (обычно 20-40 мс в одной и той же географической области, 200-300 мс между континентами) плюс нечетные 1-2 миллисекунды, которые фактически необходимы серверу для обработки запроса и отправки ответа. к розетке. Это не так уж и много времени как таковое, но умноженное на несколько сотен / тысяч запросов, быстро складывается.
Наличие от полдюжины до дюжины запросов на лету скрывает большую часть или вся эта задержка (она все еще присутствует, но поскольку она перекрывается, она не суммируется!). В то же время наличие всего нескольких одновременных подключений не имеет неблагоприятных последствий, таких как чрезмерная перегрузка или принуждение сервера к разветвлению новых процессов.
person
Damon
schedule
07.08.2012
