Какие именно данные? Новости?   Или о числе потоков? 
Т.е. у тебя умерло 50 потоков, а менеджер про это не успел узнать и запустит их только на следующей итерации?
И часто такое происходит? 
И сколько длится итерация? Разве этот простой существенный?

Хотя можешь отдать эту функцию внутрь потока. Передавай ему лимит инстансов, пусть он при своем старте сам проверяет лимит и если процессов больше, то умирает.

Какие именно данные? Новости?  smile Или о числе потоков? 
- о числе потоков, а именно число активных потоков
Т.е. у тебя умерло 50 потоков, а менеджер про это не успел узнать и запустит их только на следующей итерации?
 - да, что-то вроде этого
И часто такое происходит?
- сейчас уже нет, нашел такую вот опцию \System_Daemon::iterate и это решило проблему.
И сколько длится итерация? Разве этот простой существенный?
- итерация длиться всегда по-разному, так как это полностью зависит от внешних API с которыми мы работаем, а они могу отдавать данные за 1 секунду, а могу и за 10.
Хотя можешь отдать эту функцию внутрь потока. Передавай ему лимит инстансов, пусть он при своем старте сам проверяет лимит и если процессов больше, то умирает.
- можно, но тогда нарушается так сказать консистентность каждой единицы в системе, то есть Worker будет отвечать не за то, за что ему положено. Worker - тупой скрипт, который 
просто фетчит данные, Мфтфпук - крутой скрипт, который следит за всем =)

P.S Как я уже сказал, проблема вроде решилась. Я еще понаблюдаю за поведением но вроде пока все хорошо отрабатывает. А вообще, что можешь сказать, в правильном ли двигаюсь 
направлении использая Sys_Daemon для распараллеливания? В будущем хочу переписать систему, чтобы можно было паралеллить на ноды(отдельные сервера).

Подожди, как это?

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

Примерно так:

Очередь данных.
Очередь результатов.
Менеджер процессов
Процессы

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

Добавлено через 1 минуту

Без понятия, я с ним не работал и не знаю его возможностей.

Все имеено так и происходит =) Видимо непонятно объяснилю

Тогда не понял сути терзаний.

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

Да в приницпе терзания и проблемы уже законичлись. Рассинхронизацию исправил с помощью System_Daemon::iterate - это
аналог sleep только для задач, которые запущены в виде демонов.

Добавлено @ 21:27
Однако меня волнует текущее решение ввиде распараллеливания с помощью System_Daemon так как в системе существует
27000 запросов, которые надо делать к внешним API и распараллеливание даже на 300-400 параллельных потокв не решает полность проблемму. Проблема
опять возникнет, когда увеличиться число запросов к внешним API к примеру с в 2,3 или 4 раза то есть потребуется обрабатывать больше 100.000 запросов. Возникает
вопрос, есть ли другое решение, которое позволит адекватно решить данную задачу, я имею ввиду адекватно с точки зрения времени выполнять такое большое число запросов
к внешним API?

Это сообщение отредактировал(а) DimaSiK - 15.12.2012, 21:31

Цифры запросов не имеют никакого значения без указания времени, за которое они должны выполниться.
Ну будет у тебя 100к запросов в секунду, ну поставишь еще 1,2,3 сервера под обработчик....

Цифры должны быть адекватными:1-3 час на обработку весх запросов, а вообще чем меньше тем естественно круче. С серверами идея хорошая, я уже об этом думал,
но для этого нужно продумывать орхетектуру, которая позволила бы подключать новые ноды, когда текущие уже
не справляются с нагрузкой и менеджер должен сам организовывать корректную балансировку меджу всеми нодами.

Это сообщение отредактировал(а) DimaSiK - 16.12.2012, 11:59

У нас с одной машины свыше 10млн запросов в сутки бывало. И около 1200 пхп задач.

так что смотри по конкретному железу.

Для балансировки смотри HAproxy 

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

Как думаешь, сколько процессов потянет такая конфигурация: Ubuntu Server, Intel® Xeon® CPU X5650 @ 2.67GHz, 2 cores, 6gb RAM - это виртуальный сервер

Без понятия. Зависит от нагрузки создаваемой процессами.
300-400 запросов внешних страничек выдержать должен

Столкнулся со следующей проблеммой и ничего толковго не могу найти в интернете. Я создаю потоки обычным циклов foreach в котором идет вызов срипта, что-то типа такого:

Лимит создаваемый такии образом потоков - 400. Когда я запустил всю систему в тестовом режим, я обнаружил что менеджер никогда не заполянет пул из 400 потоков. Обычно работает 20-30 ну максимум 40 потоков. Далее я начал искать узкое место и проблема оказалось именно в использовании system. Цикл по созданию 400 потоков занимает добрых 4 минут и мне кажется это долго. Таким образом я имею не совсем параллельное создание всех 400 потоков, вернее невозможность создания одновременно 400 потоков сразу. Тестирую на слабеньком неттопе, который работает у меня в качестве домашнего dev сервера. Естественно на настоящем сервере будет быстрее и естественно будет больше больше одновременных потоков. Однако меня терзает данный момент который связан с system, может стоит попробовать исзпользваоть curl_exec или curl_multi_exec и в таком случае получить прирост к скорости создания параллельных потоков?

Добавлено через 4 минуты и 15 секунд
Может быть стоит посмотреть в сторону Python, который имеет полноценную работу с тредами да и вообще быстре в работе чем PHP?

pcntl_fork

Насчет питона ничего не скажу в синтетических тестах он не быстрее.
Код нашего питониста если и работал быстрее, то разница максимум в десятках процентов, но не в разы.
В итоге он переделал все на jython а потом и полностью на java

Но даже в этом случае скорость увеличилась всего лишь в несколько раз.
Зато было угроблено примерно 7 человеко-месяцев работы (т.е. оно себя окупит лет через 5ть не ранее)

pcntl_fork - извиняюсь, но не совсем понял приминительно к моей болячке. Блин, тогда я совсем не знаю какой выход из данной ситуации, который бы позволил обрабатывать большое количество запросов. В данный момент 26000 запросов обрабатывается примероно в течении 2-3 часов, но если количество выростет то будет задница. Я понимаю, что такого рода задачи не решаются средставми одного PHP, тогда хоть куда смотреть и на чем писать решени или что искать? какая-то тупиковая ситуация возникла. Я даже не знаю, что ответить клиенту, когда мой механизм перестанет справляться с большим наплывом запросов. Какое решение тогда ему предложить, не знаю