Демонизация на PHP

[Активист]

Задача - сделать систему демонизации, задачи:

1. Мастер управляет вокерами: запускает с определенными параметрами, в любой момент может опросить (снять стат данные, результаты выполнения процесса), убить. В случае падения вокера узнать об этом.

2. Вокеры - им мастеру нужно сообщать о результатах выполенения работы, спать или работать - должен определять мастер.

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

В какую сторону копать?

 

[AmdY]

не совсем уверен что то самое, но попробуй посмотреть на очереди http://abrdev.com/?p=1153

 

[Syra]

имхо затея так себе, php не для этого создан. Может стоит взять нечто позволяющее делать потоки, взять хотя бы для роли вокера?
Но если очень хочется, то могу предложить (банальный и упрощенный) вариант:
1. Скрипт номер один делаем работу, периодично постит результаты своей работы куда-нибудь, например в БД. Фактически держит данные своей "сессии" в БД: информация о выполнении + уникальный идентификатор + "флаг" (о флаге ниже)
2. Скрипт два считывает данные из БД, выводит если надо и может установить для любого запущенного воплощения скрипта номер один "флаг", говорящий этому первому скрипту, что ему пора умереть.

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

Если было бы известно назначения вокера, можно было бы что-то более подходящее найти.

 

[AmdY]

ой, совсем забыл, есть же ещё phpDaemon

 

[grigori]

я в том году написал свое решение для похожей задачи - обработки больших объемов почты

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

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

фиксер, вот, говорит, что нельзя вызывать очистку мусора,
впрочем, я как-то уже привык писать, что и без нее работает

 

[grigori]

AmdY phpdaemon немного на другую тему, там либивент и обработка входящих соединений

Syra замечательно создан, особенно ради сохранения однородной структуры проекта

 

[Syra]

Замечательно то замечательно, но для того ли?
Если скрипт обязан быть элементом в структуре сложного проекта - допустим. Если этого можно избежать, то имхо лучше избежать. Всякие костыли типа крона и sigterm не способны принести душевного равновесия, за то способны создать лишние сложности и проблемы.

 

[tz-lom]

Замечательно то замечательно, но для того ли?
Если скрипт обязан быть элементом в структуре сложного проекта - допустим. Если этого можно избежать, то имхо лучше избежать. Всякие костыли типа крона и sigterm не способны принести душевного равновесия, за то способны создать лишние сложности и проблемы.

реализация крона внутри какого то ещё демона видимо душевное равновесие принесёт?

 

[DYPA]

Задача - сделать систему демонизации, задачи:
1. Мастер управляет вокерами: запускает с определенными параметрами, в любой момент может опросить (снять стат данные, результаты выполнения процесса), убить. В случае падения вокера узнать об этом.
2. Вокеры - им мастеру нужно сообщать о результатах выполенения работы, спать или работать - должен определять мастер.
Задача состот в том, что бы получать в несколько потоков много данных, работать с ними, контролировать состояния загрузок, обработки этих данных.
В какую сторону копать?

перепробовал такие варианты:
1) exec + хранение состояния где нить (СУБД/nosql)
2) proc_open + stream_select (использую сейчас), подводные камни - иногда процесс отваливается раньше чем получаешь из него данные, реализация приложения - стандартный unixway

из слайдов приведённых AmdY заинтересовала Gearman

 

[Syra]

реализация крона внутри какого то ещё демона видимо душевное равновесие принесёт?

Не столько крона, сколько самих вычислений. Ну и самого крона, можно сказать, тоже. Да, принесет. Нормальные потоки, нормальное управление, реальная прозрачность. Забивать шурупы можно, но, наверное, стоит всё таки вкручивать?

 

[tz-lom]

Syra , и на чём же таком божественном вы предлагаете это писать?
никаких преимуществ такой подход не даст если требуется только контроль воркеров и возможность переноса вычислений внутрь управляющего потока не представляется возможной

 

[Syra]

Почему же божественном?
Я утверждаю скорее не то, что это стоит писать на каком то особенном языке или в среде, а что не стоит для этого использовать языки вроде php.
Если речь идёт о nix системах, то пусть будет, к примеру, си.
В чем разница решений? php не дает нормальных потоков и нормальной передачи данных между ними. В результате мы имеем костыли, которые используются с оговорками (думаю нет необходимости их перечислять). Имея же приложение, которое будет содержать в себе всё, и при этом язык, на котором написано приложение, имеет нормальные возможности по организации многопоточной работы, мы имеем приложение с куда более предсказуемым поведением и более простое в разработке и поддержке.

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

 

[tz-lom]

Да , причём в обоих вариантах , и в случае который описал Активист решение предложенное grigori выглядит лучше и проще
у меня ощущение что мы о разном говорим , нарисуйте схему для вашего варианта

 

[grigori]

Syra чукчанечитатель?
ТС спрашивал про многопоточность в одном процессе? это форум по С? кому-то есть дело до твоей правоты?
ТС дал описание архитектуры: воркеры и мастер - идеи по теме есть?

троллить иди на хабр или lor, тут обсуждается PHP

 

[grigori]

кстати, про потоки

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

что за данные? если по http/ftp - то CUrlMulti однажды у меня в 50 соединений обработал 450 000 страниц со скоростью 100-мбитного канала

 

[Активист]

Проблема в том, что нужно не только их загружать (xml+текст документа, 2 запроса, среднее время ожидания источников - 0.7 - 1 сек на 1 запрос (с учетом коннекта, ожидания ответа, полчения данных и канала) источников много), но и анализировать (очень много анализировать по тексту, строить цепочки), а результат класть в базу уже "для употребления" (2 млн) судебных доков, ежедневный прирост 1-4%. Я хочу запускать 8 вокоров на 4 ядра с HT. Выборки из БД идут крайне долго (сложные выборки на первоначальном этапе, использование инексов по максимум, но 3-4 секунды на запрос (выборка из очереди) ), поэтому работать с БД крайне не рекомендовано. Делаю что бы данные брались мастером и выдвались вокерам (через $argv). Опытным путем установлено, что если не загрузить все ядра по полной, то анализ и загрузка займет около 2-х месяцев, а это непозволительная роскошь.

Задача такая - мастер запускает процесс загрузки допустим 1 тысячи доков на 1 вокера (туда мульти курл), возвращает список местеру, вокер получает новый список, как только один документы загрузился, передается мастером другому вокеру, который уже пошел работать с текстом (анализировать, строить цепочки), создавать PDF/RTF/DOC копии, индексы. Далее мастер (или его потомок) должен запустить индексатор (после сотни успешно обработанных документов) сфинкса и добавить в индекс, далее склеить индексы.

Сейчас вместо мастера - я и консоль, остальное (по большей части) реализовано (за иск. сфинкса), но это не проблема, ничего никуда не течет (по 3-4 дня работали до этого скрипты).

Вот собственно задача.

Спасибо за ссылки, почитаю.

 

[Активист]

grigori
Как делал сигналы? Передача данных между процессами?

 

[Активист]

Пока курю вот это: http://docs.php.net/manual/en/ref.pcntl.php

 

[Syra]

grigori, я внимательно прочитал тему, "на PHP" увидел. Ответ непосредственно по сабжу дал. Что может мне запретить посоветовать то, что на мой взгляд значительно лучше? То что это форум о php? Если у кого-то есть молоток, то это не значит, что он должен делать им всё подряд, как бы хорош, прост и удобен не был этот молоток.

в случае который описал Активист решение предложенное grigori выглядит лучше и проще

То что писал Активист в первом посте мне показалось несколько туманным
Решение из первого поста grigori на практике выливается в то, что нецелевое применение php приведет к возможному появлению разного рода ошибок, о которых ничего не скажут ни доки, ни логи. Ни огромный размер оперативной памяти под каждый php скрипт, ни неограниченное время выполнения, ни какие ещё либо блага цивилизации и настройки веб сервера и интерпретатора php не гарантируют спокойной жизни. Было бы иначе, речь не шла бы о том, что надо

по крону запускаться и проверять, жив ли другой управляющий

"и о том, что

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

И опять же синхронизация данных между потоками, если так можно назвать несколько запущенных экземпляров php скрипта, при работе с php отнюдь не сахар.

троллить иди на хабр или lor, тут обсуждается PHP

В споре рождается истина, нет?

При массовой скачке данных всё упрется в ширину канала, и, возможно в скорость дисковой подсистемы.
А при обработке? Теперь, точнее зная задачу, можно предположить что на обработку будет потрачено большая часть времени. Точно сказать что будет быстрее при операциях обработки данных нельзя, не проведя тестов с подходящей подборкой операций, но чует моё сердце, что php (созданный немножко для другого) проиграет тому же c++ в несколько раз, а скорее даже в несколько десятков раз, даже не учитывая возможности оптимизации под имеющийся процессор.

Зачем советовать что попало? Оно будет разработано не быстрее, работать будет (по крайней мере во время обработки информации) гарантированно медленнее и вполне вероятно нестабильно, возможны возникновения специфических проблем из-за используемых костылей...и опять же существует простое, готовое и проверенное решение для использования всех ядер многоядерного процессора, и это не язык для веб-программирования, а разные языки для разработки прикладных программ.

P.S.
Не вижу никакой разницы между нашими с вами, grigori, первыми ответами (решениями) на поставленный вопрос.

 

[tz-lom]

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