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 <[email protected]> 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 <[email protected]> >> >> 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 <[email protected]> 작성: >> >> 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, <[email protected]> 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 >> >> [email protected] >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > > -- > > > Sincerely yours, > > Apostolis Xekoukoulotakis > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
