Распараллелить работу части скрипта?

Question

[Станислав Гамаюнов]

Приветствую.


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

1. Читаем из базы исходные данные, готовим и разбиваем на порции. Это довольно быстро.
   
2. Итерируем массив порций, отправляем каждую в API, получаем ответ, пишем его в базу. А вот это очень медленно.
   
3. Обрабатываем все полученные данные, пишем ещё и результат обработки. Это тоже довольно быстро.
   

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

1. Gearman. Но, кажется, это что-то не совсем то или я не понимаю, как с ним работать. Мне не нужно просто сплавить работу воркерам, мне нужно запустить их именно параллельно и дождавшись результата работы всех воркеров, выполнить финальное действие. Может быть нужно добавить задачи как фоновые, а потом смотреть на список задач на job-сервере?
   
2. pcntl_fork. Здесь не до конца понимаю принцип работы: в какой-то момент у меня есть массив довольно больших объектов. Мне нужно выполнить отправку частей этого массива с разными параметрами (разные реквизиты доступа к API, например). В таком случае, понадобится форкнуться нужное число раз, получить «приветы» от клонов, раздать им данные и ждать от каждого ответа? Или я всё усложняю?
   
3. Ещё думал дожидаться завершения работы потомков по каким-нибудь .pid файлам.
   

Но что-то мне подсказывает, что существует какое-то иное решение или лучшее понимание проблемы.

Заранее спасибо за подсказки.

Answer 1

[sajgak]

Gearman как раз то. Он поддерживает паралельный запуск задач и получение ответа по завершению (aka callback) через методы (doNormal, doHigh, doLow).
С форками работать сложнее, но тоже можно. Для каждой итерации вы форкаете новый процесс и записываете куда то результат, вопрос только в том, как потом общий результат прочитать. В общем я бы вам посоветовался поближе разобраться с gearman

Comments

[Станислав Гамаюнов]

В общем я бы вам посоветовался поближе разобраться с gearman

Да, мне и самому бы хотелось.

Сейчас я представляю себе это так: запускаю основной процесс, тот готовит данные, разбивает на партии, запускает n фоновых тасков и впадает в while (хотя бы один таск ещё выполняется) { sleep (1); }, затем собирает данные и работает дальше. Данные воркерам можно отдавать через memcache и через него же принимать результаты.

Звучит работоспособно, спасибо.

[sajgak]

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

Answer 2

[Urvin]

2. pcntl_signal даст сигнал об окончании работы дочернего процесса.
Когда работал с этими функциями долго не мог врубиться в совершенно теские вещи. Работа идет примерно так:
а) Вешаем обработчик pcntl_signal. Это сигнал об окончании какого-то из процессов.
б) Циклично форкаемся, предварительно записывая в некую переменную номер пакета данных. По справке определяем — копия/не копия.
в) если копия, posix_setsid, деаем нужный код или через pcntl_exec замещаем себя обработчиком пакета.
В этом месте обработчик пакета принимает возвращенные сторонним сервисом данные и как-либо их обрабатывает.
г) По завершении работы дочернего процесса мы знаем его PID и, соответвенно, знаем индекс обработанного пакет.

3. ps x и читаем вывод. Знаем PID и прочие атрибуты процессов. Но некошерно.

Comments

[Станислав Гамаюнов]

Более-менее понял, как работать с pcntl. Спасибо.

Однако звучит грязновато. Будь-то собираюсь писать свою реализацию xml-парсера. Думаю, если использую в этом проекте Gearman, получу более реюзабельные и высокоуровневые знания.

[Urvin]

Грязновато?
Стандартно! Без ненужных оберток в виде высокоуровневых знаний!

[Станислав Гамаюнов]

Мне предстоит форкаться в конроллере приложения, где есть открытые коннекты к БД, куча загруженных ресурсов. Коннекты придётся закрыть. Затем там же if (если я дочерний) {} else {}. При этом, в воркерах мне все эти ресурсы и коннекты не понадобятся. Но после их отработки понадобятся вновь.

Это вместо того, что бы просто $gearmanClient->doBackground('task1', 'task1_1');, а дальше только крутиться в while, дожидаясь когда все задачи будут выполнены, собрать результаты из memcache и работать с ними не теряя окружения.

А ещё, для сервера очередей, думаю, всегда найдётся больше задач, чем для для pcntl в PHP.

Answer 3

[javax]

Не знаю, насколько это актуально для Вас, но я такого типа скрипты пишу на Groovy
Там можно и треды запустить для параллельной работы

Comments

[Станислав Гамаюнов]

Очень много бизнес-логики, применяемой для обработки данных, о которых идёт речь, уже написано на PHP. Для одной конкретной задачи не решусь переписывать всё это. К тому же на Groovy не писал и понадобится время на въезд.

Но в очередной раз задумался о более развитых языках и платформах, спасибо.

Answer 4

[strib]

Смотря как лежат данные.
Если в БД и включены транзакции, то я бы сделал так.
1) Форкнулся необходимое количество раз.
2) Транациями брал из базы набор записей и обрабатывал. Записи были бы блокированы. Ну или анонимной транзакцией помечал как исполняемые (хз можно ли в MySQL так сделать)
3) После закрытия транзакции — взять очередную порцию.

Comments

[Станислав Гамаюнов]

Данные перед отправкой обрабатываются все вместе, одним огромным массивом. И только части результата обработки отправляются в сторонний API. Т.е. воркерам фактически и нечего обрабатывать, нужно только делать асинхронные вызовы API.
Потому использование/неиспользование транзакций в этой задаче не играет роли.

В любом случае, спасибо за ответ.

[strib]

КМК играет, т.к. надо как то блокировать элементы очереди во избежание повторной обработки.
Исходя из вышесказанного.
1) Предобработка данных
2) Куча параллельных обработчиков, которые делят между собой очередь. Самф просто способ, опять же с моей точки зрения, возложить эту почетную обязанность на базу.
3) Постоработка.

[Станислав Гамаюнов]

В момент раздачи порций воркерам для отправки в API, данные хранятся в памяти большим массивом. И записываются в базу только когда слетают в API по частям, вернутся обратно, обработаются ещё раз. Зачем их в процессе снова писать в базу? (к тому же, данные не простые key-value, а массивы с несколькими уровнями вложенности).

Answer 5

[Вячеслав Слинько]

Очень крутой фреймворк для async приложений на php — reactphp.org

Comments

[Станислав Гамаюнов]

Интересный фреймворк. Выглядит как какой-то NodeJS на PHP. Спасибо за указание.
Но у меня лишь одно место в проекте нужно распараллелить (может и несколько, но точно таким же образом).

[Вячеслав Слинько]

Да, он вдохновлен js.

Почему не таким? Если вы думаете что сложно, то нет: создаете пару объектов, запускаете Loop::run() и все.

[Станислав Гамаюнов]

Почему не таким?

Я писал, что именно таким.

Правильно понимаю, что мне нужно будет запустить на reactphp простенький сервер, который будет ждать команд от моего приложения, а по ним запускать параллельное их выполнение? Если так, то это похоже на гораздо менее универсальную реализацию gearman. Возможно на её запуск потребуется меньше времени. Но я больше склоняюсь к Gearman.

[Вячеслав Слинько]

Упс, не так прочел.

Нет, никакого сервера — все локально в вашем процессе.

[Вячеслав Слинько]

Могу помочь в скайпе.

[Станислав Гамаюнов]

Посмотрел examples/parallel-download.php. Выглядит очень круто. Это магия прямо в моём старом-добром PHP.

Позже посмотрю на свой код и, веротяно, попробую применить. Спасибо ещё раз.

[Вячеслав Слинько]

Да, PHP сейчас в самом разгаре, что и подтолкнуло меня к нему вернуться с django.

Удачи вам :)