Hi Andrew,
DisruptorMessageQueue already batches reads but the implementation differs
from what is done in BatchEventProcessor. BatchEventProcessor gets events
one by one from the ring buffer and at the same time sends them to the
event handler. But while BatchEventProcessor controls its event handler,
DisruptorMessageQueue isn't aware of its recipients. So on the first
dequeue call DisruptorMessageQueue gets all available events from the ring
buffer and puts them into its internal buffer. On subsequent dequeue calls
it just retrieves and returns the events from the internal buffer.
To implement batch writes in DisruptorMessageQueue Akka should support
something like a batch tell. It can be easily emulated by sending a set of
messages as an array or collection. And it will be even more efficient
because Akka will construct an Envelope only for one message rather than
for each message from the set.
вторник, 7 января 2014 г., 4:39:48 UTC+2 пользователь Andrew Carroll
написал:
>
> Hi Igor,
>
> I've implemented an Actor-type system (and as it stands, Akka IO) as a PoC
> using the Disruptor myself and was waiting for the day a good
> implementation becomes available for Akka!
>
> My experience is -- and everything that the LMAX developers say -- backs
> up the claim that the best performance from the RingBuffer comes when
> batching operations, as this decreases the frequency of memory fencing
> instructions executed. Essentially, use the RingBuffer for inter-core
> communication only.
>
> So far I've only had a quick glance at your code and don't have really any
> knowledge of the internals of Akka's message passing. Do you see any
> opportunity within your implementation to batch writes and reads?
>
> On Monday, 6 January 2014 21:34:55 UTC+11, Igor Konev wrote:
>>
>> Hi Roland,
>>
>> Although you mentioned above that hasMessages is called upon every tell
>> operation, it looks like it is not the case. Not taking BalancingDispatcher
>> into account hasMessages is called from Mailbox's
>> canBeScheduledForExecution as follows
>>
>> final def canBeScheduledForExecution(hasMessageHint: Boolean,
>> hasSystemMessageHint: Boolean): Boolean = status match {
>> case Open | Scheduled ⇒ hasMessageHint || hasSystemMessageHint ||
>> hasSystemMessages || hasMessages
>> case Closed ⇒ false
>> case _ ⇒ hasSystemMessageHint || hasSystemMessages
>> }
>>
>> But hasMessages and hasSystemMessageHint are never false at the same time
>> when canBeScheduledForExecution is called (indirectly) from Dispatcher:
>>
>> protected[akka] override def registerForExecution(mbox: Mailbox,
>> hasMessageHint: Boolean, hasSystemMessageHint: Boolean): Boolean = {
>> if (mbox.canBeScheduledForExecution(hasMessageHint,
>> hasSystemMessageHint)) { //This needs to be here to ensure thread safety
>> and no races
>> ...
>>
>> protected[akka] def dispatch(receiver: ActorCell, invocation:
>> Envelope): Unit = {
>> val mbox = receiver.mailbox
>> mbox.enqueue(receiver.self, invocation)
>> registerForExecution(mbox, true, false)
>> }
>>
>> protected[akka] def systemDispatch(receiver: ActorCell, invocation:
>> SystemMessage): Unit = {
>> val mbox = receiver.mailbox
>> mbox.systemEnqueue(receiver.self, invocation)
>> registerForExecution(mbox, false, true)
>> }
>>
>> So hasMessages is never called upon tell.
>>
>> пятница, 3 января 2014 г., 10:51:33 UTC+2 пользователь rkuhn написал:
>>>
>>> Hi Igor,
>>>
>>> thanks for sharing! On first (cursory) sight it looks like your mailbox
>>> might cause missed wake-ups because head and tail are read by the
>>> enqueueing thread without synchronization (i.e. disruptor cursor is moved
>>> but updates to head and tail have not been published; this might be
>>> mitigated by clever ordering of effects, but my spidey senses make me
>>> uneasy on this one).
>>>
>>> Regards,
>>>
>>> Roland
>>>
>>> 1 jan 2014 kl. 20:04 skrev Igor Konev <[email protected]>:
>>>
>>> > If somebody is still interested, I've implemented a bounded mailbox
>>> using Disruptor and obtained a throughput gain of about 50% over the
>>> standard bounded mailbox. You can find the source code here
>>> https://github.com/yngui/akka-disruptor.
>>> >
>>> > --
>>> >>>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>> >>>>>>>>>>> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> > To post to this group, send email to [email protected].
>>> > Visit this group at http://groups.google.com/group/akka-user.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>> Dr. Roland Kuhn
>>> Akka Tech Lead
>>> Typesafe – Reactive apps on the JVM.
>>> twitter: @rolandkuhn
>>>
>>>
>>>
>
> This email is confidential and intended solely for the person(s) to whom
> it is addressed.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.
