Внутренний модуль модуля удаленного вызова процедур Erlang - PullRequest
3 голосов
/ 17 марта 2011

У меня есть несколько приложений Erlang на узле A, и они делают вызовы rpc к узлу B, на котором у меня есть хранимые процедуры Mnesia (функции запросов к базе данных) и моя база данных Mnesia.Теперь время от времени число одновременных процессов, выполняющих вызовы rpc в узел B для получения данных, может возрасти до 150. Теперь у меня есть несколько вопросов:

Вопрос 1: Для каждого rpcвызывая удаленный узел, делает ли узел А совершенно новое (скажем, соединение TCP / IP или UDP или что-то еще, что они используют на транспорте) СОЕДИНЕНИЕ?или существует только одно соединение, и все вызовы rpc совместно используют это соединение (поскольку узел A и узел B связаны [связано с этим процессом epmd])?

Вопрос 2: Если у меня есть приложения, ориентированные на данные, на одном узле, а у меня база данных Mnesia с централизованным управлением на другом, и таблицы этих приложений используют одну и ту же схему, которая может быть реплицирована, фрагментирована, проиндексирована и т. Д., Что является лучшим вариантом: использоватьrpc вызывает для извлечения данных из узлов данных в узлы приложений или для разработки целого нового фреймворка, используя, скажем, TCP / IP (способ, которым ребята Scalaris сделали это для своего детектора сбоев), чтобы удовлетворить проблемы с задержкой в ​​сети?

Вопрос 3: Кто-нибудь когда-либо проводил тестирование или тестирование производительности системы RPC таким способом, который может ответить на следующие вопросы?
(а) Какое максимальное число одновременных вызовов rpc, которое узел Erlang может протолкнуть на другой без поломки?
(b) Есть ли способувеличить это число, либо из-за конфигурации системы, либо из-за настройки операционной системы?(обратитесь к Open Solaris для x86 в своем ответе)
(c) Существуют ли другие способы для приложений запрашивать данные у Mnesia, работающие на удаленных узлах Erlang, кроме rpc?(скажем, CORBA, REST [требуется сквозной HTTP], Megaco, SOAP и т. д.)

1 Ответ

4 голосов
/ 17 марта 2011

Mnesia работает поверх распределения erlang, а в распределении Erlang между любыми парами узлов имеется только одно соединение tcp / ip (обычно в полностью сетчатом расположении, поэтому одно соединение для каждой пары узлов). Вся связь rpc / internode будет происходить по этому распределительному соединению.

Кроме того, гарантируется, что порядок сообщений сохраняется между любой парой взаимодействующих процессов при распределении. Порядок между более чем двумя процессами не определен.


Mnesia дает вам много вариантов размещения данных. Если вам нужно постоянное хранилище на узле B, но обработка выполняется на узле A, у вас могут быть disc_only_copies ваших таблиц на B и ram_copies на узле A. Таким образом, приложения на узле A могут получить быстрый доступ к данным, и вы все равно получить надежные копии на узле B.

Я предполагаю, что сеть между A и B является надежной локальной сетью, которая редко собирается разделить (в противном случае вы собираетесь потратить кучу времени, чтобы вернуть mnesia в оперативный режим после раздела).

Если и A, и B используют mnesia, то я бы позволил mnesia сделать для меня все RPC - это то, для чего построена mnesia, и она имеет ряд оптимизаций. Я бы не катил свой собственный RPC или механизм распространения без очень веской причины.


Что касается тестов, то полностью зависит от вашего оборудования, схемы mnesia и сети между узлами (а также от шаблонов доступа к данным вашего приложения). Никто не может дать вам эти ориентиры, вы должны сами их запустить.

Что касается других механизмов RPC для доступа к mnesia, я не думаю, что есть какие-либо из готовых, но есть много библиотек RPC, которые вы могли бы использовать для представления API mnesia в сети с небольшими усилиями на вашем компьютере. часть.

...