[zeromq-dev] Actor Model

[Gleb Peregud]

Erlang solves this the following way:
- one OS thread is run per cpu core (such thread is called a scheduler)
- each erlang actor (called "process") is a very lightweight thread
- each scheduler has it's own independent run queue
- Erlang virtual machine handles load balancing of erlang processes
between schedulers by migrating them between
- if scheduler's run queue is empty it steals work from other
schedulers (get's an erlang process from another scheduler and adds it
to own run queue)
- if scheduler's run queue is too long it gives away some erlang processes

Sockets are handled by some sort of kernel polling and each socket is
assigned to specific erlang process.

I am a developer of two Erlang systems which are capable of handling
1MM+ TCP sockets on one physical server. Google for "Oortle erlang
factory" to see a presentation about it. It was optimized for
broadcast speed. It sends 1MM of 500 byte messages to 1MM of users
from one physical server and end-to-end latency over LAN is < 1.5s
(i.e. last client gets the message in at most 1.5 second after
broadcast has been initiated).

On Sat, Dec 15, 2012 at 2:29 PM, Apostolis Xekoukoulotakis
<xekoukou at gmail.com> wrote:
> This question is of interest to me as well.
>
> Let me give some answers, I havent really implemented them yet:
>
> 1. Each thread has one socket. You hash the unique name of the actor and
> assign it accordingly to a thread.
> advantages: no contention.
> disadvantages: it cannot work if actors have different processing needs.
>
> You rely on the randomization of the hash function to balance the work.
>
> this is pretty useful for a graph processing system(millions++ of actors)
>
> 2.You have a central broker which implements a locking mechanism. Threads
> ask for work, they receive the actors name plus the message that needs to be
> processed.
> All the actors data are shared by all the threads.
>
> advantage:load balancing works all the time
> disadvantage: latency because each thread has to request for work.
>
>
> From an algorithmic point of view, how is a disruptor pattern faster than a
> queue when we want to implement an actor model?
>
> I would be interested to know how akka or erlang solve the above problem of
> distributing actors to threads.
>
>
> 2012/12/15 Min Yu <miniway at gmail.com>
>>
>> Akka on zeromq would be an another fun for you.
>>
>> http://doc.akka.io/docs/akka/snapshot/scala/zeromq.html
>>
>>
>> Thanks
>> Min
>>
>> Dec 15, 2012 9:01 PM Gleb Peregud <gleber.p at gmail.com> 작성:
>>
>> If you want the most natural way to code your program according to
>> actor model, just use Erlang. It has a zeromq library, hence you can
>> communicate with outside world using zmq.
>>
>> On Sat, Dec 15, 2012 at 12:27 PM,  <wilfried at hafner.ws> wrote:
>>
>>
>> hi peeps,
>>
>>
>> i would like to ask you for some ideas/hints on an actor-model
>>
>> design on top of zeromq. zeromq ships with everything i need,
>>
>> a mailbox, message routing, i don't have to worry about threads etc.
>>
>>
>> i think the straightforward way would be to give every actor
>>
>> one or more sockets for sending and receiving messages, depending
>>
>> on the used patterns (pub-sub, req-rep). but it seems to be a big
>>
>> overhead, since the max. number of sockets per context is limited.
>>
>> on the other hand, i would have to share some sockets and write
>>
>> a lot of messaging features by myself. so zeromq would be useful
>>
>> just for the communication between some processes or nodes.
>>
>>
>> it's similar to an component based entity system, communication between
>>
>> entities<->entities, entities<->system and system<->system
>>
>> should be handled through an event/message bus. Although it's not for game
>>
>> development, 10k+ entities are possible, which would require
>>
>> at least more than 10k sockets.
>>
>>
>> thank you for your suggestions!
>>
>>
>> best regards,
>>
>>
>> wil
>>
>>
>> _______________________________________________
>>
>> zeromq-dev mailing list
>>
>> zeromq-dev at lists.zeromq.org
>>
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
>
> --
>
>
> Sincerely yours,
>
>      Apostolis Xekoukoulotakis
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>