Здравствуйте, Geralt, Вы писали:

G>Большое спасибо за ответ.

A>>Сканер пишем?
G>Скорее чекер живых URL с некоторой дополнительной функциональностью.

G>>>2. Префорк, SysV IPC и однонаправленный канал.
A>>Приемлимо, но слишком простая задача, для этого... к тому же если надо сразу по 1000 ури сканить... 1000 процессов рожать?
G>На перле у меня получалось родить 100 процессов, но там каждый процесс включает в себя интерпретатор и весит около 5-8 метров. Плюс какие-то неясные проблемы с sysv IPC, которые не позволяли изменять шаровый массив размером более 10 элементов, поэтому приходилось действовать по следующей схеме: родитель проверяет пуст ли хеш параметров, если да, локает, пишет в него, анлокает. Дочерние процессы "набрасываются" на хеш. Тот, кто успевает его локнуть получает параметры, опустошает и анлокает. Родитель замечает, что хэш пуст и пишет в него новые значения. И т.д. Таким образом в секунду происходило 30-60 локов, анлоков и записей в шаровую переменную, что тоже очень сильно грузило систему.

G>>>4. Претрединг.
A>>Другое название Job Manager. Тоже что и 2, но тоже быстрее. И тоже тут избыточно.
G>В обще-то я склонялся к этому варианту т.к. считал его самым быстрым и наименее ресурсоемким.
A>>Для данной конкертной задачи это все нафиг не нужно.... быстрее всего будет работать FSM в одном процессе.
G>What does FSM mean? =)

Любой межпроцессный IPC довольно медленная штука... если нет супер необходимости не стоит ее использовать.
Такую архитектуру нужно использовать только для публичных сервисов, типа apache. Где нужна безопастность.
Если нужна именно скорость, то либо threads либо FSM. Finite State Machine. В простонародии "конечный автомат"
В принципе возможен вариант для многопроцессорных машин, когда таких FSM-процессов рождается по кол-ву процов.
Но сетевуха одна, по этому сильного выигрыша не получится.

A>>ЗЫ: там же есть ссылки на разные сканеры на этой либе... можете проверить сначала как это работает будете приятно удивлены.
G>Постараюсь проверить в ближайшее время. Учитывая тот факт, что единичным заданием является выполнение head запроса, а затем get в случае, если некоторые данные (время модификации, например) удовлетворяют некоторым критериям, каково количество заданий может обрабатываться в секунду (канал очень широкий =)?

Ограничения только по ширине канала. Т.е. допустим канал 300кб (по инету быстрее наврядли будет работать).
Время отклика сервера 35мс. Итого на скан одного сервера тратится (нижняя граница)
1. 35 * 3 = 105мс (syn+sack+ack)
2. 35 + 35 = 70мс (head)
Итого суммарный объем трафика будет где-то ~1к и 175мс на запрос.

Получаем при 300кб за 175мс = 300запросов. за секунду 300 * 1000 / 175 = 1714 запросов в секунду. или 10к в минуту.

Это естветвенно нижняя граница. В принципе ping сканер работает с такой скоростью на данной библиотеке, но там и пакетов всего 2 .
По этому реальная скорость будет где-то 1000 запростов в минуту (опять же зависит от опрашиваемых URL). Если они будут все тупить,
то одновременно можно хоть 10к сокетов открыть (на забуть FD_SETSIZE поправить). И однвовременно ждать со всех них ответ.
При этом это будет всго один процесс .

G>И, чтоб не создавать дополнительную тему, какие существуют библиотеки по типу libwww для перл (классы Request, Response, Cookies, работа с SSL и т.д.)?
С перлом работал очень давно... да и то на сторное сервера... там такое пользовать не приходилось.


ЗЫ: сорри если где-то прогнал , 1-е число однако .