Здравствуйте, netch80, Вы писали:

Поскипаное выше внимательно прочитано. Очень сильно совпадает с опытом, полученным при эксплуатации разработанных на базе SObjectizer систем.

N>>>Большие объёмы данных, много параллельных запросов и плотные потоки — это три разных случая, обычно не сильно пересекающиеся. Свидетель описывает случай 3, который на штатном рантайме, считаем, нереализуем. Случай 2 — самый подходящий. 1 — зависит от подробностей.
S>>Отрадно, когда в треде появляются люди, понимающие что к чему
S>>ИМХО, со вторым случаем, т.е. с потоком параллельных запросов, так же не все однозначно. Можно создавать по воркеру на каждый запрос. А можно иметь отдельный воркер на ядро, а запросы представлять внутри воркера в виде конечных автоматов. И у того, и у другого подхода есть свои достоинства и недостатки.

N>В случае Erlang обычно достаточно по воркеру на запрос. Это проще всем, потому что такой воркер отработал и застрелился, не требуется никакой сложной зачистки за ним. Если же это выводить в пул автоматов, как минимум уже утяжеление, что GC должен реально отработать, а не прихлопнуть целиком всю память застрелившегося процесса. Ну и сами автоматы писать достаточно громоздко. Нам в Clustrx пришлось идти по пути автоматов, потому что надо было хранить состояние объекта со множеством подробностей между оповещениями от него, и я помню неудобства, связанные с этим.

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

Пусть, например, каждая активность -- это отдельный процесс (нить, короутина). Может случиться так, что у нас в результате какого-то всплеска образовалось 100K активностей и практически все они должны быть убиты по тайм-ауту. Если каждая активность — это отдельная сущность, которая сама взводит таймер, то можно ожидать затем всплеска таймеров и, соответственно, большого расхода ресурсов на обработку этих таймеров. Аналогичная проблема возникает, когда активности периодически должны повторять свои действия (отослали запрос в стороннюю систему, не получили ответ за 10 секунд, отослали запрос повторно, опять заснули и так несколько раз). Здесь так же можно ожидать всплесков таймеров.

Если активность -- это KA внутри воркера, то достаточно нескольких таймеров, при срабатывании которых проверяется, есть ли активности, подлежашие удалению из-за истечения срока жизни. Если есть, то убиваются N из них. Затем можно проверить, есть ли активности, для которых нужно повторение чего-либо (запроса в стороннюю систему) и обслуживается K из них. И т.д. и т.п. При этом можно контролировать времена, затраченные на каждом из шагов и, в зависимости от них, выбирать значения N, K и т.д.

Все это пересекается с одним из пунктов, описанных вами выше: "Допускается постоянно живущих в объёме M*Ncores, где M — достаточно малая константа. Допускается огромное количество (грубо говоря, миллионы) процессов, но чтобы каждый из них жил одну операцию (самое крупное — ответ на http запрос, или транзакция), не постоянно, и чем короче — тем лучше (нижняя граница срока жизни — определяется моментом, когда переброс данных между такими эфемерами становится слишком дорогим)." Как раз воркеры с представлением активностей в виде KA являются способом решения проблемы больших значнией M. Но вы об этом, по-моему, сами же и сказали.