Держать свой пул постоянно или брать под задачу

Хочу разобраться до конца, по верхам уже пробовал.

Ниже вводные, дальше сам вопрос.

Трафик за месяц вышел около двух терабайт, поэтому пакеты гигабайтов не подходят. Сравнивал два пула на одинаковой задаче, разница по времени вышла в полтора раза.

Кто как это обходит?

Разбейте прогон на части, станет ровнее.

Добавлю то, что обычно вылезает на второй месяц работы.

Скорость адреса и скорость прогона это разные вещи. Прогон упирается в темп, который вам позволяют. Ширина канала на это влияет слабо.

$ for a in $(cat pool.txt); do curl -s -o /dev/null -w "%{time_total} " -x $a https://example.org/; done
0.412 0.398 1.884 0.421 0.406

Замечание по существу, иначе расчёт поедет.

Безлимитный трафик выгоднее пакетов на любом регулярном сборе. Два терабайта в месяц набегают незаметно, а на пакетах это отдельная статья расходов.

На такой задаче адреса надо держать свои. Общий пул тут подведёт. Общий пул делится с незнакомыми людьми, и лимит вы никогда не контролируете. Я беру приватные прокси IPv4 и SOCKS5 и сплю спокойно.

Дополню, потому что важная деталь потерялась.

Считайте не только пул, но и запас на замену. Часть адресов выбывает по естественным причинам, и это надо закладывать.

Серверные адреса берут скоростью и стабильностью. Для съёма позиций, обхода каталогов и мониторинга цен этого хватает с запасом.

$ for a in $(cat pool.txt); do curl -s -o /dev/null -w "%{time_total} " -x $a https://example.org/; done
0.412 0.398 1.884 0.421 0.406

Проходил ровно этот путь года полтора назад.

Пул под мониторинг и пул под разовый прогон устроены по-разному: первому важна ровность, второму запас по объёму.

Соглашусь, хотя пришёл к этому через неприятность.

Число адресов считается от темпа. Возьмите допустимый темп на адрес для конкретной площадки и разделите на него общий темп прогона. Полученное умножьте на два, это и будет рабочий пул.

Подтверждаю по своей практике.

Подсети важнее числа. Сорок адресов из одного диапазона площадка видит как одну руку, а десять из разных диапазонов ведут себя как десять разных посетителей.

Смешивать задачи на одном пуле можно, но осторожно: тяжёлый прогон съедает лимит, и лёгкая задача рядом начинает ловить отказы.

$ for a in $(cat pool.txt); do curl -s -o /dev/null -w "%{time_total} " -x $a https://example.org/; done
0.412 0.398 1.884 0.421 0.406

Замечание по существу, иначе расчёт поедет.

Пинг смотрите последним. На длинном прогоне сорок миллисекунд разницы теряются в паузах между запросами.

У коллеги было то же самое, причина оказалась смешной.

Скорость канала важна там, где вы качаете тяжёлые страницы. На сборе выдачи она почти не влияет на общее время.

$ for a in $(cat pool.txt); do curl -s -o /dev/null -w "%{time_total} " -x $a https://example.org/; done
0.412 0.398 1.884 0.421 0.406

Пишите состояние построчно.

Поправлю цифру, остальное верно.

Считайте не только пул, но и запас на замену. Часть адресов выбывает по естественным причинам, и это надо закладывать.

Тема нужная, подписался.