Процессы воркеров попробуй создавать не через 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