Как лучше распараллелить вычисления php?

Question

[Александр Мельниченко]

Есть набор значений который рассчитываются по элементарным математическим формулам (+-*/).
Эти значения зависят от коэффициентов, коэффициенты хранятся в базе.
Часть коэффициентов динамические(меняются примерно раз в сек), часть почти статика.

Нужно распараллелить вычисления для максимально быстрого просчета.
БД mysql.

Изза того что данные очень динамические сильно на кеш не завяжешься.

Из вариантов - разнести на очередя, и по мере нагрузки добавлять воркеров.

Запросы на просчет могут приходить как массово до 5тыс значений, так и точечно 1-5 значений

Comments

[Stalker_RED]

Меняются в базе раз в секунду? Насколько много этих коэфициентов, не лучше ли их в память загнать?

[Александр Мельниченко]

Помимо этих расчетов они используются во многих местах из разных проектов(репозиториев, поддоменов....), с поддержкой есть много ньюансов

Answer 1

[Смотритель]

Что по мне, так зря вы так думаете по теме кеширования в памяти... Кешировать ведь можно не только конечный результат, отправляемый юзеру, но и эти часто изменяющиеся данные.
Тот процесс, который постоянно изменяет данные в базе ведь может их не только в БД писать, но и в кеше сразу обновлять (мемкеш/редис/etc.). И для выдачи результата не базу постоянно трясти, а брать их из кеша - это быстро.

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

Ну а если не поможет, тогда уже думать над распараллеливанием потоков и т.д.

Comments

[Иван Шумов]

Redis это хорошо, но чуйка у меня что задача не с того конца решается

[Смотритель]

Иван Шумов, все может быть... у меня недавно тоже проект был по распределенным вычислениям, там тоже параметры формул динамические и на каждом из узлов они должны актуализироваться, решил через очереди + редис + БД на случай непредвиденных обстоятельств... в принципе работает без проблем, обрабатывает спокойно порядка тысячи "вычислительных потоков" в секунду в штатном режиме, не пиковом...

[Иван Шумов]

Артем, архитектура она такая) подождем ответа автора. 2 архитектора на сломавшего себе голову недостаточно опытного, полагаю, разработчика. Справимся) тем более что задачка, вроде, интересная

Answer 2

[Иван Шумов]

По вашему описанию пока что выглядит как типовая задача для RMQ + Work queues Consumers, но! Меня очень смущает то что вы написали о коэффициентах, которые меняются раз в секунду в базе. Основная цель коэффициентов быть статическими значениями уравнения расчета.

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

Comments

[Александр Мельниченко]

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

Z1.......Zn = A+B-C*Y+D/X

,
помимо этого X и Y еще много где учавствует

[Иван Шумов]

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

[Imrahil]

Вот основной вопрос это РТ или не РТ)
А так вполне подойдет любой pub/sub messaging тот же Редис.