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

прикольно, чтобы проще запускать синхронные запросы(inline_requests)?

в общем параметр CONCURRENT_REQUESTS мне в помощь?

ммм, мое глубокое имхо, скрапи тут не подойдет.
тут надо полностью свое писать. Но это не для новичка, дохрена что надо предусмотреть и прописать.

в первую очередь чтобы можно было ходить асинхронно в базу, в файлы, руками в сеть (не через requests, который синхронный), но и сделать встроенный аналог inline_requests тоже тикет есть

CONCURRENT_REQUESTS это про очередь запросов в одном процессе, а я про несколько процессов

а про CONCURRENT_REQUESTS по моей ссылке есть

почему не подойдет?

1. читаешь что такео многопоток на многоядерных системах
2. читаешь что такое аснхрон и с чем его едят
3. читаешьчто такое "access violation at address" (наверняка в питоне такое то-же есть), ужасаешся
4. куришь бумажки, карандаши и кучу мануалов

в результате получаешь п..ц насколько шуструю систему которая выполняет конкретно твою задачу.

тебе надо обрабатывать 100500 страниц по принципу "кто первый встал того и тапки?" если да, то скрапи чуть для другого. Это универсальная система, которую пожно заточить под парсинг 99% сайтов. Но в универсальости как факта кроется куча всяких "не хорошестей".
Мне никто не докажет что полностью написанная и заточенная под конретную ситуацию система не будет быстрее чем скрапи, пускай даже оптимизированный до бровей

но, если тебе надо "прям щас что то написать", то да, можно и на скрапи "накостылить" :). как минимум, для первичной оценки темы подойдет.
хотя, х/з, может тебя устроит и как окончательный продукт :)

да, все верно

я тоже думал самописанное что-то, но надо щас на коленках

сайтов сколько?

где там чувак с тредпулом, самое то жы

ну, больше миллиона

сайтов или урлов?

вообще вот broad crawl гуглить

сайтов

со словом scrapy или без