Re: [spray-user] IO worker in Spray
244 views
Skip to first unread message
Mathias
Aug 30, 2012, 8:59:57 AM8/30/12
to spray...@googlegroups.com
Samira,
sprays IO module (spray-io) differs from Akkas own IO implementation in a number of important ways, mostly in the type of trade-offs we made with regard to performance and functional style. Also, spray-io gives you a number of additional features, like write confirmations, event/command pipelines and SSL support.
spray-io's IoWorker (to be renamed to "IoBridge" in 1.0-M3) is not an Actor because being a (properly behaving) Actor would actually inhibit it from doing its work in the most efficient way. The IoWorker occupies one thread all for itself and uses it to manage a single Java NIO selector in the most performant way we know. In order to do this it has to be able to block.
Akka 2 actors work best if they do not block at all. Using an actor to manage a NIO selector (as Akkas IOManager does) is possible, but (IMHO) suboptimal.
Therefore we deem our approach of implementing an IO bridge between Java NIO and Akka actors superior to the IOManager implementation coming with Akka.
Cheers,
Mathias
---
mat...@spray.cc
http://www.spray.cc
On 30.08.2012, at 14:08, Samira Tasharofi wrote:
> Hi all,
>
> I am looking into your code for Spray. I just found a class named IoWorker.
>
> It is surprising that it implements a functionality of an actor; but you didn't use actors. Since Akka has IOManagerActor which is for managing IO, why didn't authors use that for the application and decided to go with their own IO implementation?
>
>
>
> Thanks,
>
> Samira
>
>
> --
>
>
sprays IO module (spray-io) differs from Akkas own IO implementation in a number of important ways, mostly in the type of trade-offs we made with regard to performance and functional style. Also, spray-io gives you a number of additional features, like write confirmations, event/command pipelines and SSL support.
spray-io's IoWorker (to be renamed to "IoBridge" in 1.0-M3) is not an Actor because being a (properly behaving) Actor would actually inhibit it from doing its work in the most efficient way. The IoWorker occupies one thread all for itself and uses it to manage a single Java NIO selector in the most performant way we know. In order to do this it has to be able to block.
Akka 2 actors work best if they do not block at all. Using an actor to manage a NIO selector (as Akkas IOManager does) is possible, but (IMHO) suboptimal.
Therefore we deem our approach of implementing an IO bridge between Java NIO and Akka actors superior to the IOManager implementation coming with Akka.
Cheers,
Mathias
---
mat...@spray.cc
http://www.spray.cc
On 30.08.2012, at 14:08, Samira Tasharofi wrote:
> Hi all,
>
> I am looking into your code for Spray. I just found a class named IoWorker.
>
> It is surprising that it implements a functionality of an actor; but you didn't use actors. Since Akka has IOManagerActor which is for managing IO, why didn't authors use that for the application and decided to go with their own IO implementation?
>
>
>
> Thanks,
>
> Samira
>
>
> --
>
>
Samira Tasharofi
Sep 1, 2012, 10:24:21 PM9/1/12
to spray...@googlegroups.com
Thank you very much Mathias for your response. That would be really helpful.
Cheers,
Samira
Derek Williams
Sep 1, 2012, 11:23:26 PM9/1/12
to spray...@googlegroups.com
On Thu, Aug 30, 2012 at 6:59 AM, Mathias <mat...@spray.cc> wrote:
spray-io's IoWorker (to be renamed to "IoBridge" in 1.0-M3) is not an Actor because being a (properly behaving) Actor would actually inhibit it from doing its work in the most efficient way. The IoWorker occupies one thread all for itself and uses it to manage a single Java NIO selector in the most performant way we know. In order to do this it has to be able to block.
Akka 2 actors work best if they do not block at all. Using an actor to manage a NIO selector (as Akkas IOManager does) is possible, but (IMHO) suboptimal.
Therefore we deem our approach of implementing an IO bridge between Java NIO and Akka actors superior to the IOManager implementation coming with Akka.
Just to add to this, Akka's IOManager was written at a high enough level so it could run on any Akka dispatcher, without needing to manage it's own thread. It was originally implemented with it's own thread, but both myself and Viktor Klang found it to not be very 'Akka-like'. This is also reflected in the decision to make sure that all data going to/from the IOManager was immutable, even though to create the fastest IO implementation possible you'd need to be working the the buffers directly.
It very nearly performs as well as running the selector in it's own thread, but of course there is a bit of overhead. Raw NIO is not that difficult, so it makes sense that if every bit of performance is needed that a custom implementation is best.
Derek Williams
Mathias
Sep 2, 2012, 6:16:41 PM9/2/12
to spray...@googlegroups.com
Derek,
thanks for your comments!
> Just to add to this, Akka's IOManager was written at a high enough level so it could run on any Akka dispatcher, without needing to manage it's own thread.
> It was originally implemented with it's own thread, but both myself and Viktor Klang found it to not be very 'Akka-like'.
Yes, I assumed that your goal was to pay a certain price in terms of performance and implementation complexity for the advantage of having the IOManager be a regular Actor. This way it is a good Akka citizen and benefits of all the perks regular Actors enjoy now (and in the future).
sprays IO implementation also tries to be "Akka-like", but in the sense of "fighting for every allocation" and reducing overhead to the minimum in order to deliver max performance (while still upholding a "good" architecture). We have decided to sacrifice "being an Actor" on this altar.
The current prime beneficiary of this is the spray-can HTTP server, which is built on top of spray-io and should be one of the fastest web servers on the JVM.
(Event though there is certainly some optimization potential left in the spray-io implementation... Our goal is to capture it all eventually.)
> This is also reflected in the decision to make sure that all data going to/from the IOManager was immutable, even though to create the fastest IO implementation possible you'd need to be working the the buffers directly.
Right. This is another area where spray-io differs from "akka-io".
There are more. For example, the Akka IOManagerActor employs a number of mutable maps to associate things like SelectableChannel and WriteBuffers with a connection handle. Since these maps are queried and updated in various places in the "hot path" they can add measurable overhead (cycles, memory), especially when the IOManager has to deal with tens of thousands of connections.
sprays IOBridge implementation doesn't use a single map, all required association of support structures happens through selector key attachments.
On the other hand "akka-io" appears to also support file IO rather than just network IO (which is what spray currently limits itself to).
So, on the bottom line it appears as if our two teams have made a number of slightly different design choices that give our users two sufficiently different implementations of an adapter layer between NIO events/commands and Akka Actor messages.
In the short-term the main job that is left for us to do on the spray side is to properly document our contraption, thereby also contrasting it with "akka-io", so that our users are aware of the differences and able to make a conscious and informed choice.
> --
>
>
thanks for your comments!
> Just to add to this, Akka's IOManager was written at a high enough level so it could run on any Akka dispatcher, without needing to manage it's own thread.
> It was originally implemented with it's own thread, but both myself and Viktor Klang found it to not be very 'Akka-like'.
sprays IO implementation also tries to be "Akka-like", but in the sense of "fighting for every allocation" and reducing overhead to the minimum in order to deliver max performance (while still upholding a "good" architecture). We have decided to sacrifice "being an Actor" on this altar.
The current prime beneficiary of this is the spray-can HTTP server, which is built on top of spray-io and should be one of the fastest web servers on the JVM.
(Event though there is certainly some optimization potential left in the spray-io implementation... Our goal is to capture it all eventually.)
> This is also reflected in the decision to make sure that all data going to/from the IOManager was immutable, even though to create the fastest IO implementation possible you'd need to be working the the buffers directly.
There are more. For example, the Akka IOManagerActor employs a number of mutable maps to associate things like SelectableChannel and WriteBuffers with a connection handle. Since these maps are queried and updated in various places in the "hot path" they can add measurable overhead (cycles, memory), especially when the IOManager has to deal with tens of thousands of connections.
sprays IOBridge implementation doesn't use a single map, all required association of support structures happens through selector key attachments.
On the other hand "akka-io" appears to also support file IO rather than just network IO (which is what spray currently limits itself to).
So, on the bottom line it appears as if our two teams have made a number of slightly different design choices that give our users two sufficiently different implementations of an adapter layer between NIO events/commands and Akka Actor messages.
In the short-term the main job that is left for us to do on the spray side is to properly document our contraption, thereby also contrasting it with "akka-io", so that our users are aware of the differences and able to make a conscious and informed choice.
>
>
Reply all
Reply to author
Forward
0 new messages