Стала задача распараллелить задачу на несколько потоков и по окончанию работы всеx потоков, собрать результаты выполнение воедино. Каким образом это лучше всего сделать?

Это сообщение отредактировал(а) DimaSiK - 10.6.2012, 23:05

Посмотри в сторону очередей RabbitMQ, Apache ActiveMQ
Возможно подойдет Gearman

Да Gearman как раз то, но было бы крута, если бы треты могли обмениваться между осбой информацией.

Хотел спросить, правильно ли я понял работу Gearman. Есть Client часть которая создает очередь задач. Worker же в свою очередь - скрипт, который к примеру зпускается каждую минуту CRON и фетчит из текущей очереди задачи. То есть правильно ли я понимаю, что если я создал Cliento-ом 10 обычных задач, затем Worker запустился первый раз - зафетчил первую задачу, потому опять запустился - зафетчила вторую задачу и так далее до 10. Все задачи запущены и Client ожидает теперь выполнения всех 10 задача?

http://php.net/manual/en/book.shmop.php

Или те же самые очереди через pub/sub



Ждать не обязательно.
Можно проверить результат через некоторое время.


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

А можно повесить один в виде демона, который будет дергать столько инстансов скрипта сколько надо

Или те же самые очереди через pub/sub
 - ага, то есть к примеру я могу использовать Redis для хранения/изменений состояния каждого из worker и таким образом будет осуществляться обмен данными между тредами?
Ждать не обязательно.
Можно проверить результат через некоторое время.
 - А вот меня интересует такой вопрос, насоклько моя схема будет эффективно работать и может можно предложить что-то другое, более лучшее.

Схема:
1. Существует Клиент, который посредставм Gearman создает пускай 10 бекграунных задач.
2. Клиент создал задачи и ушел в цикл ожидания результатов от всех задач.
3. Каждая из задач работает в фоном режиме и обменивается данным посредствам Redis. Таким образом каждая из задча
    в любой момент времени знает состояние остальных.
4. Задачи отработали, Клиент проверяет результаты и выполянет post бработку данных.

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

Что скажешь?

Как один из вариантов - да.


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


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

Спасибо за информацию.

А можно повесить один в виде демона, который будет дергать столько инстансов скрипта сколько надо 
- можешь немного натолкнуть по этому направлению?

У нас делали при помощи кода из этого
http://efiquest.org/2011-10-22/55/ 

Т.е. висит скрипт в виде демона и по fastcgi дергает php-fpm.

Не изобретайте велосипед, Erlang в помощь для таких задач.

Таких это каких?

Столкнулся с проблеммой доступа к БД. То есть master процесс может выбирать данные, но они уже будут неактуальны, так как уже
были изменены дочерними процессами. Есть какая-нибудь ифнормация по этомй проблемме?

Блокировки. Но это просадит общую производительность.

Какого рода данные?
Любые данные обычно имеют свой период устаревания.
Если для ЦУП это секунды и меньше, то для каких-нибудь там счетчиков посещаемости это минуты.

Добавлено через 3 минуты и 21 секунду
Да, еще уровни изоляции транзакций можешь почитать

В чем суть: есть 'менеджер' который запускает столько потоков, сколько считает нужным но не больше определенного количества, чтобы не убить совсем систему. После создания 'менеджер' уходит
в бесконечный цикл ожидания и добавления новых потоков в случае, когда поток/потоки уже отработали. Таким образом 'менеджер' следить за тем, чтобы в единицу времени было запущенно всегда
максимум потоков. 'менеджер' в принятии своего решения запускать новый поток/потоки всегда опирается на таблицу текущего статуса запущенных рпроцессов. Каждый процесс меняет себе статус сам и есть признак окончания, что процесс уже отработал. И возникает иногда проблема, что 'менеджер' выбирает данные, которые не являются уже актуальными, то есть они были уже изменены но он еще об этом не знает, а узнает уже в следующей итерации. Я решил не привязываться к German, хотя до этого его очень хорошо понял. Все построено на базе ZF2, Doctrine и Sys Daemon. Поток 'менеджера' - один и работает как демон вечно, дочерних потоков может быть и 200 и 300 в общем любое количество не угрожающее падению сервера. Каждый поток так же работает как демон, который заканчиваеи свою работу. Связь всех потоков осуществляется через едную таблицу MySQL, доступ через Doctrine.

Добавлено через 1 минуту и 48 секунд
Совсем забыл про твои вопросы:
Какого рода данные?
- тянем новости из различных API. Делаем агрегатор новостей на вырост
Любые данные обычно имеют свой период устаревания.
- обсалютно не существенно

Какие именно данные? Новости?   Или о числе потоков? 
Т.е. у тебя умерло 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, тогда хоть куда смотреть и на чем писать решени или что искать? какая-то тупиковая ситуация возникла. Я даже не знаю, что ответить клиенту, когда мой механизм перестанет справляться с большим наплывом запросов. Какое решение тогда ему предложить, не знаю   

Процессы воркеров попробуй создавать не через system


Профилирование делал?

Что является узким местом?
Какая нагрузка на сервер при этом?




масштабируй его по серверам.
В чем сложность?

Я понял, попробую.


кстати отличная идея и надо будет посмотреть. Спасибою


ну это едиснственное что остается в данной ситуации так как других решений я не нашел вообще.

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

Не хочется создавать новую тему, ведь проблема та же самая только уже на другом уровне. Итак, распараллеливание все таки было сделано с использованием System_Daemon. Были также написаны менеджеры которые порождают воркеров и затем успешно и безотказно управляют ими. В общем то что раньше система выполняла за 6-8 часов а то и 10 часов, сейчас выполняется всего лишь за час а то и меньше. Так же было проведено много оптимизация SQL запросов и stuff алгоритмов. Система работает очень стабильно и быстро но как всегда появляется опять 'НО'. В общем количество клиентов растет и данная архитектура через 1-3 месяца перестанет справляться с нагрузкой в рамках одного сервера + так как backend очень нагружен и как следствие подмораживает frontend. В данный момент сервер загружен на 99% и стоит вопрос переработки архитектуры backend таким образом, чтобы он мог масштабироваться на любое количество серверов. Как всегда имеются вопросы которые я хочу разрешить путем обсуждения так как ничего особенного и определенного по данной теме я найти не смог. Может быть плохо искал - тогда тыкните меня и я с удовольствием ознакомлюсь. В общем как я себе представляю будущую систему:

Высокоуровневая архитектура:

•  Существует frontend сервер. Собственно он существует только для визуализации данных и взаимодействия пользователей с этими данными
•  Master сервер. Сервер хранит все данные. Собственно мощный DB сервер.
•  Worker сервера. Их может быть сколь угодно, все зависит от нагрузки. Сервер отвечает за загрузку данных из внешних API, как-то их анализирует и затем выгружает данные на Master сервер.

Как это будет работать:

Master сервер должен иметь свой private API. По данному API с ним могут общаться frontend сервер а так же Worker сервер. Frontend  сервер использует API для запроса данных и дальнейшей визуализации пользователям. Worker сервер использует API для: 1. анализа данных, 2. сохранения данных 

Проблемы которые я вижу:

1. Пользователи могут создавать критерии, которые влияют на входные данные  - вопрос где лучше хранить эти данные? Если хранить критерии на Master сервере, то в таком случае каждый Worker  сервер будет дергать Master сервер на предмет новый критериев. Хранить критерии на Worker серверах вообще не вариант, так как возникнут проблемы с их синхронизацией.

2. Каждый Worker сервер при анализе данных должен опираться обязательно на данные которые находятся на Master сервере. К примеру анализ на предмет повторения требует перебора по всем имеющимся данным в рамках одного аккаунта пользователя.  В таком случае Worker сервер будет пользовать private API Master  сервера, что так же ведет к высокой нагрузке Master сервера.

Итог:

Получается что даже если разнести систему на несколько серверов, узким местом в таком случае является Master сервер, который будет нагружен всеми Worker серверам и как следствие просто не будет справляться с запросами от Frontend сервера и опять же как следствие Frontend будет подтормаживать при выдаче результатов. Так все же есть ли какое-то вразумительное решение в данной ситуации и возможно ли данное решение на PHP?

причем тут php?
Это репликация, шарды, партиции, кластер БД и т.д.


Каким образом влияют эти критерии на сами данные-то?
Что такое критерии вообще?
Условия для выборок?

Сорри, не так выразился. Стоит ли вообще все это затевать на PHP?



Все верно, это некие ограничения, фильтры что ли, применяя которые к внешним API система получает искомые данные.

Что именно? репликацию? шардинг? партиционирование?
Ни один из этих вопросов не имеет к php никакого отношения, но зависит от БД.
Т.е не имеет значения будет использоваться php или нет.



Беря ложку мы зачерпываем из тарелки и едим суп.
Вопрос, стоит ли готовить суп в ложке? Или его лучше замораживать вилкой?

Вот примерно так же выглядят и твои объяснения.

К каким таким внешним API? Если у тебя




На пальцах
Есть твоя БД которая может не выдержать наплыва запросов.
Есть какая-то пачка скриптов (worker)  для асинхронного наполнения БД.
Есть сами фронтенды.

Если упираешься в БД - масштабируешь БД.
Если упираешься в скорость и число worker - масштабируешь их
Если упираешься в фронтенды для чтения из БД и отображения пользователям - масштабируешь их.

В чем вопрос?

Это сообщение отредактировал(а) Fortop - 17.7.2013, 01:23