Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:20
    tesgu commented #4806
  • Mar 08 15:30
    Aaronontheweb commented #4806
  • Mar 08 15:13
    Aaronontheweb labeled #4814
  • Mar 08 15:13
    Aaronontheweb labeled #4814
  • Mar 08 15:13
    Aaronontheweb commented #4814
  • Mar 08 15:13
    Aaronontheweb review_requested #4814
  • Mar 08 12:37
    Arkatufus synchronize #81
  • Mar 08 12:37
    Arkatufus opened #81
  • Mar 08 12:28
    Arkatufus commented #70
  • Mar 08 12:25
    Arkatufus commented #70
  • Mar 08 12:24
    CumpsD commented #70
  • Mar 08 12:22
    Arkatufus commented #70
  • Mar 07 09:13
    tesgu closed #4806
  • Mar 07 09:11
    tesgu commented #4806
  • Mar 06 21:34
    SamEmber edited #4814
  • Mar 06 21:24
    SamEmber commented #4813
  • Mar 06 21:23
    SamEmber closed #4813
  • Mar 06 21:23
    SamEmber opened #4814
  • Mar 06 21:01
    SamEmber opened #4813
  • Mar 06 17:19
    to11mtm commented #70
coffeeyesplease
@coffeeyesplease
These guys have their own machines/data center
Aaron Stannard
@Aaronontheweb
but yeah, that sounds like a lot of messages
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
coffeeyesplease
@coffeeyesplease
Yeah. My first job is to actually reduce the number of messages
it did some remoting testing.. and firing 1M took the sender something 700ms...
Aaron Stannard
@Aaronontheweb
/flex
coffeeyesplease
@coffeeyesplease
but a bit longer to get to the other side
Aaron Stannard
@Aaronontheweb
one thing I haven't tested
but would like to
hmmm, actually
Roger Johansson
@rogeralsing
Do we have any benchmarks on remoting throughput?
Aaron Stannard
@Aaronontheweb
@rogeralsing not really - I've benchmarked Helios before and it's able to handle a pretty stupid amount of traffic without falling down
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
coffeeyesplease
@coffeeyesplease
[disclaimer]: I’m not experienced with neither helios os Akka.Net
Aaron Stannard
@Aaronontheweb
I think everything gets done as an actor selection
coffeeyesplease
@coffeeyesplease
I’ve with helios and it was damn fast
Aaron Stannard
@Aaronontheweb
so it takes some time to resolve each of those to an ActorRef
coffeeyesplease
@coffeeyesplease
I can’t remember teh numbers but it was really fast, but for some strange reason I was losing some of the messages
Aaron Stannard
@Aaronontheweb
if it was the same message each time and it didn't get logged by dead letters then it could be an issue with Helios' message decoding
Roger Johansson
@rogeralsing
Actually, i did see some messageloss when i had the students writing their paper
coffeeyesplease
@coffeeyesplease
hmmm!!!
Aaron Stannard
@Aaronontheweb
next thing I'm working on after we ship Akka.Cluster is Helios 2.0, which has a better model for dealing with that problem
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)
Roger Johansson
@rogeralsing
Aaron, we should take a look if that was just my naive testcase or if it is a real issue
Aaron Stannard
@Aaronontheweb
if you have some bits that you can send me i can take a look
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
coffeeyesplease
@coffeeyesplease
yeah, I try and find the test
Aaron Stannard
@Aaronontheweb
the decoder reads some bytes that aren't actually the length-frame header
assumes the message is corrupt
and discards bytes until the buffer is empty
coffeeyesplease
@coffeeyesplease
it as basically sending logs messages the around. 128 len string
Aaron Stannard
@Aaronontheweb
it's possible that there's some race conditions I never caught with the reactive part of the socket
Roger Johansson
@rogeralsing
Found their test, mailed you
Aaron Stannard
@Aaronontheweb
thanks
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
Aaron Stannard
@Aaronontheweb
@rogeralsing btw, have virtual nodes and all of that fun stuff implemented now
had to rewrite our Murmur3 implementation in order to support it
(followed the Scala implementation - it wasn't so different from mine, just optimized for being able to construct a hash in discrete steps)
(rather than treating it like a black-box all-or-nothing operation)