исходя из каких параметров лучше регулировать количество потоков/процессов 4 crawler

Ну если с трафиком проблем нет - то наращивать, пока загрузка процессора не будет близка к 100%. (Либо пока канал не загрузится полностью - смотря что раньше наступит).

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

Cейчас crawler на perl'e. Но думаю переписывать на java (встроенная многопоточность). Схему контроля думаю сделать такой:

-у crawler_manager'a есть список сайтов

-например manager запустил на скачку 10 crawler'ов

-те начинают качать... например на главной страничке 20 ссылок... у crawler'a составляется список страниц данного сайта... crawler запускает 20 потоков (на каждую страницу 1 поток)... каждый поток отслылает crawler'y время получения страницы... crawler суммирует время от всех потоков... (хотя нет, они же параллельно работают... тогда выбирает максимум) и отпраляет это значение crawler_manager'y тот в свою очередь сравнивает показания всех 10 crawler'ов (так же еще он память должен смотреть...) и принимает решение запустить на скачку еще 1 сайт или сказать crawler'y, который больше всего времени ждет сервер, что нужно остановить поток, или вообще остановить crawler...

списки сайтов и стрниц сайтов ( + флаги ) думаю хранить в key-value БД (почитал этот форум... все говорят что юзать СУБД накладно...). нашел berkeley-db java edition...

вот только думаю не сильно-ли завернутая схема... кто какую схему применяет вообще, и стоит ли на java все это делать (почему решил java = анализ тектса + потоки + пороще С++)...

Если crawler написан правильно, то у вас раньше исчерпается канал или же вы достигните максимума скорости записи на диск, нежели доведёте загрузку процессора до 100%, поэтому при построении планировщика лучше закладываться на задаваемые лимиты скорости канала и скорости записи на диск.

Это если не индексировать на ходу, то в диск/канал упрешься. А с индексированием - как раз скорее всего именно в процессор.

По-моему слишком сложно. Существуют готовые средства для очередей, с готовыми же блокировками. Можно держать общую на весь процесс очередь заданий на скачивание, пул потоков-рабочих - которые достают задание из очереди, и выполняют, и поток-контроллер - который мониторит размер очереди, если он превышает какой-то порог - порождает новые потоки (до определенного предела), если наоборот - останавливает старые.

Страниц, которые предстоит выкачать? По идее имеет смысл их хранить в коллекциях java, и готовыми же методами "зеркалить" в БД, с помощью ORM типа hibernate.

Ну Java это вообще штука сильно на любителя. :) Посмотрите еще в сторону python - для качальных дел неплох, да и сам по себе язык приятный очень.

Если есть сложный анализ текста то возможно что процессор будет основным ограничением а по поводу пропускной способности канала возможно что процессор тоже будет ограничением потому что TCP/IP набор протоколов тоже надо кому то обрабатывать.

Думаю, с одновременным индексированием упретесь все-таки в проц. ресурсы и память. А что значит "встроенная многопоточность"? На мой взгляд, многопоточность есть практически везде, где есть форканье и треды.

А вот на джаве программить не люблю: конечный продукт сожрет больше ресурсов, чем та же прога, написанная на сях или перле... мое личное наблюдение.

Это скорее python на любителя, ...

C без плюсов уже не модно?

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

вот интересен этот порог... как его посчитать... (там же потом еще и индексирование будет работать...) А что за готовые средства... попобдромнее можно.?..

про java да, согласен -)) есть повод изучить его получше...

на питон смотрел раньше чем на java, подкупает еще и тем что google на нем роботов написал -)

Нет. Форки - это форки, со всей радостью в виде неудобной IPC, заботы о блокировках и т. п.

А треды к примеру в том же перле - нельзя юзать, многие либы не thread-safe, в частности самые ходовые LWP и HTML::Parser/HTML::Tree.

На С писать с тредами? Это попухнуть можно. Прибавка в скорости просто не стоит седых волос. :)

Да на глазок. Он же особого смысла не несет - допустим в очереди 10000 урлов - значит надо еще добавить качальщиков, или наоборот - очередь пустует - значит надо покилять качальщиков, чтоб процессор у индексаторов не отбирали.

Я имею ввиду работу с очередями.

http://www.python.org/doc/2.4.2/lib/module-Queue.html - отличная штука. Просто до безобразия, полностью thread-safe - в общем от кучи лишней работы избавляет.