Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:29
    Aaronontheweb commented #3863
  • 21:28
    Aaronontheweb synchronize #3863
  • 21:18
    Aaronontheweb synchronize #4000
  • 21:17
    Aaronontheweb commented #3964
  • 21:17
    Aaronontheweb commented #3964
  • 21:16
    Aaronontheweb synchronize #3964
  • 21:12
    Aaronontheweb commented #3964
  • 21:08
    Aaronontheweb synchronize #71
  • 21:04
    Aaronontheweb synchronize #3973
  • 21:00
    Aaronontheweb commented #71
  • 20:58

    Aaronontheweb on dev

    Akka.Persistence.TCK fix - chec… (compare)

  • 20:58
    Aaronontheweb closed #4002
  • 20:51
    Aaronontheweb synchronize #4002
  • 20:45
    Aaronontheweb commented #3811
  • 20:45
    Aaronontheweb commented #3811
  • 20:44
    Aaronontheweb labeled #4002
  • 20:43
    Aaronontheweb milestoned #4002
  • 20:43
    Aaronontheweb opened #4002
  • 20:37
    Aaronontheweb synchronize #71
  • 20:20
    Aaronontheweb synchronize #71
Aaron Stannard
@Aaronontheweb
but if each actor only has to process a single message at the lowest level of the hierarchy
Ash R
@AshRolls
so back of the hand 1 mill messages per sec on my hardware is around the correct value?
Aaron Stannard
@Aaronontheweb
the other thing about dispatcher thoughput
it only increases the throughput of a given actor if you adjust that setting exclusively
if everyone's throughput setting goes up, no one's does
(insert exceptional edge cases here where the system isn't that busy, etc)
but in a busy system, that's true
so typically where you see a lot of benefit in increasing the dispatcher throughput is when you use it on a small number of actors who receive a disproportionately large number of messages relative to everyone else
Ash R
@AshRolls
I'll try and optimise the architecture to reduce context switching then
Aaron Stannard
@Aaronontheweb
on our CI system we run on a crappy Windows Azure VM
D2 V2
has two cores
a single actor can do about 4.3-4.5 million messages per second
but that's because its dispatcher is constantly running
Ash R
@AshRolls
I saw the pingpong example mentioned in f#
Aaron Stannard
@Aaronontheweb
yeah, the ping pong example is a better benchmark for looking at context switching costs
they start to show up once the number of actors running exceeds the number of cores by some scalar value
in a typical Akka.NET system in production
you have a large number of actors, but at any given instant only a proportion of them have messages to process
the majority are idle, if you took a snapshot at any given millisecond
Ash R
@AshRolls
thanks for your help, I have some ideas now
Aaron Stannard
@Aaronontheweb
excellent, glad to hear it
Ash R
@AshRolls
reduce messages by batching
Aaron Stannard
@Aaronontheweb
please feel free to ask questions here or on StackOverflow
Ash R
@AshRolls
ty, very helpful. loving akka.net so thanks for the devs work on it
Aaron Stannard
@Aaronontheweb
thanks!
We have some cool stuff coming out again soon too
verilocation
@verilocation
I'd second that. Also it's nice to have such good support through this!
Ash R
@AshRolls
I just had nice speed boost by not creating a new object each time I need to create a message to send / return
Juan José De Arana
@juanjoarana
Hello, a colleague complained that it's not that easy to design an Actor model, where you can make any logical unit an actor. Specially when local message passing requires serialization, which I guess means a performance penalty. Is it possible to configure AKKA.NET to avoid message serialization when passing messages between actors in a local system? E.g.: passing messages objects by reference (ensuring they are immutable)... or doing a deep copy/clone of the message object? Thanks!
verilocation
@verilocation

The other day I asked a question regarding Ask... Someone kindly showed me a related link (http://bartoszsypytkowski.com/dont-ask-tell-2/). I have since been trying to position myself whereby I no longer have to use Ask but have come up against an issue.

Previously:

  • My ProcessActor Asked the GeocodeActor
  • The GeocodeActor Asked the GeocodeCacheActor for a cached geocode response, if it has one, Tell back to the ProcessActor
  • Failing that it would Ask the ReverseGeocodeActor to reverse geocode against Google, and then Tell to the GeocodeActor who would in turn Tell to the ProcessActor
  • At this point the GeocodeActor would Tell the GeocodeCache to cache the result

Since then I now do the following

  • My ProcessActor Tells the GeocodeActor to geocode
  • The GeocodeActor has a local cache, if its hit itll Tell the sender the geocode (the sender, ProcessActor, has a receive event for this, and stores a list of pending models)
  • If one doesn't exist it will Forward the request to ReverseGeocodeActor to reverse geocode. This would ideally then Tell the response back to the original sender, the ProcessActor.

Unfortunately I can't figure out how to cache the response without an Ask as the ReverseGeocodeActor will see that the sender is the original ProcessActor...

Ash R
@AshRolls
instead of forwarding why don't you get the GeocodeCacheActor to Tell the ReverseGeocodeActor, and send it the IActorRef of the process actor as a prop. The ReverseGeocodeActor can then send the response to the ProcessActor, as well as a Tell back to the GeocodeCacheActor with the data to cache?
verilocation
@verilocation

Ash dont suppose you have a code example? Currently I do this in the GeocodeActor when I ask the ReverseGeocode

this.ReverseGeocodeActor.Forward(p);

Which then Tells back to the ProcessActor like so

this.Sender.Tell(geocodedAddress);

In this case how would I tell the GeocodeActor to cache the result

Ash R
@AshRolls
In the geocode actor, take the contents of the message p, and put it in a new message type which contains those contents, as well as an IActorRef to Sender (which at this moment will be the ProcessActor). Then Tell that message to the ReverseGeoCode actor.
verilocation
@verilocation
ahhhh
I understand you now... Does it not seem.. wrong.. to store the sender in a POCO rather than use akka somehow itself.
Ash R
@AshRolls
In the ReverseGeoCode actor, you can then Tell Sender (GeocodeCacheActor) with the data to cache, and you also have the IActorRef so you can send ANOTHER message to tell the ProcessActor
as for structure... can't say sorry, I have been sending IActorRef around in my messages without problem, it seems pretty lightweight
if it's a set structure you can send it just once in the constuctor of the agent
verilocation
@verilocation
Oh now that sounds better
Ok that works a charm, I like that, thank you
Ash R
@AshRolls
np
Marc Piechura
@marcpiechura
@juanjoarana Akka.net only serialize messages if they are send over the wire and we use the object ref and don't do deep cloning because that would hit the performance, so we have by default the requirement for immutable messages
Andrew Young
@ayoung
@Horusiath issue created #2340
John Nicholas
@MrTortoise
@AshRolls re not creatign messages: so you used some kind of static instance? or do you mean you had a pool of messages to use?
himekami
@himekami
Hi, anyone knows how to create cluster singleton using FSharp API ? What should I pass to SpawnOption list (I'm guessing i have to use SpawnOpt) ?
Gregorius Soedharmo
@Arkatufus
question, since the async and await keyword is pretty much banned in akka.net, do i need to use PipeTo in ReceiveAsync?
and i'm not allowed to do something like... ReceiveAsync<MyClass>(async message => {}); ?
John Nicholas
@MrTortoise
you can still use tasks. They are useful in those cases.
when using tasks the ReceiveAsync seems to be the way if you do not want your actor to be reenterant (which is probably the case otherwise you can have state changes prior to the PipeTo or ContinueWith continuation