Hi Kenneth,

the current state of Akka Streams is that we want to get the functionality 
implemented in a correct fashion first and optimize later. You are right that 
optimistic write-through would be more performant, but the implementation of 
that scheme requires a lot more care because on the other side the Reactive 
Stream input needs to signal the “right” amount of demand, taking into account 
the possibility of receiving a NACK later. In effect this will lead to yet 
another buffer between the stream and the socket, which is certainly not ideal, 
so we will need to spend some effort in minimizing that while retaining the 
throughput advantage.

If you want to experiment with different schemes and contribute measurements or 
even alternate implementations you would be most welcome!

Regards,

Roland

2 jun 2014 kl. 01:58 skrev Kenneth Owens <kowens0...@gmail.com>:

> My questions pertain to the choice of ack based write throttling in the 
> reactive streams implementation using Akka. I currently have multiple, Akka 
> based, Protocol Buffers via TCP services running in production at my company, 
> and, like the group at spray, I tend to prefer nack based write throttling 
> with read suspension back pressure (Empirically, I've found this method to be 
> much more performant). From review of the source, it seems that the writePump 
> will buffer all incoming data prior to demand being established and any 
> outstanding writes being complete, concatenate the buffered data into a 
> single ByteString, and then send the data to the underlying TCP actor 
> managing the NIO selector for the connection.
> 
> Is my understanding correct?
> If so why has this method been selected instead of optimistic write through?
> Am I missing some implication of this method with respect to dynamic back 
> pressure control? It seems that better performance might be gained by writing 
> to the NIC optimistically until CommandFailed occurs, and that, as the back 
> pressure here is applied by the kernel TCP buffers and I/O device, it should 
> not affect downstream remote  subscribers or affect the back pressure balance 
> between remote hosts
> 
> Thanks you in advance for you reply,
> -K
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn


-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to