Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 16 22:15
    Aaronontheweb synchronize #3889
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3986
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3985
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump FsCheck.Xunit from 2.9.0 t… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3983
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump ApprovalUtilities from 3.0… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] edited #3985
  • Oct 16 21:00
    dependabot-preview[bot] edited #3986
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3982
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3987
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump FsPickler from 5.2.0 to 5.… (compare)

  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump LightningDB from 0.9.8 to … (compare)

  • Oct 16 21:00
    dependabot-preview[bot] edited #3982
  • Oct 16 21:00
    dependabot-preview[bot] edited #3983
  • Oct 16 21:00
    dependabot-preview[bot] edited #3987
  • Oct 16 20:59
    dependabot-preview[bot] edited #3982
  • Oct 16 20:59
    dependabot-preview[bot] edited #3985
  • Oct 16 20:59
    dependabot-preview[bot] edited #3987
  • Oct 16 20:59
    dependabot-preview[bot] edited #3986
John Nicholas
@MrTortoise
whats the recommended goto Receive handler these days?
Aaron Stannard
@Aaronontheweb
but just grokking from where the wind blows here
10 seconds to do that sounds reasonable, and I'll explain right now
the biggest cost to processing a message, usually other than the work the actor actually has to perform when it receives a message, is the context switch on the dispatcher
Ash R
@AshRolls
Yes, that was my assumption
Aaron Stannard
@Aaronontheweb
in your case there isn't that much work since it looks like each child is just sending a basic ACK back
Ash R
@AshRolls
yup this is just the test case. I thought the context switching was taking the time, hence the fiddling with custom-dispatcher throughput
Aaron Stannard
@Aaronontheweb
the dispatcher throughput can't and won't affect the context switching overhead in this scenario
what the dispatcher throughput will do is allow one actor to hang onto the dispatcher for longer before it yields to another
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