I was going to say
I hope your EC2 sales rep / whatever vendor you use drives a nice car
These guys have their own machines/data center
although in-process messages within akka.net are dirt cheap from an overhead point of view
remote messages, less so - serialization overhead on both ends of the connection can add up
it did some remoting testing.. and firing 1M took the sender something 700ms...
but would like to
hmmm, actually
something like 250,000 reads per second on 2 threads at 3-4% CPU
never done anything like that for Akka.Remote though
what I'd like to do ideally is add a benchmarking system for Akka.Cluster
test how different cluster sizes perform
and make it pluggable for people's apps
as for what you were saying @coffeeyesplease - I think the reason the recieving end is slower is because of how remote messages get delivered to their recipients
it's going to follow Netty's design much more closely than the current version
(Akka.Cluster will ship after Akka.NET 1.0 is released)
if it's a Helios issue then I know exactly where the problem is
it's the
LengthFrameDecoder
either it or the
ByteBuf sitting on top of it grabs only a partial chunk of a message
assumes the message is corrupt
and discards bytes until the buffer is empty
I'll take a look at that
I've had a spec written down on paper, quite literally - in my notebook, for Helios 2.0 and I'm desperate to work on it because I think it'll finally be easy to work directly with Helios once I've made those changes :p
Helios' current API is simple but not the most intuitive