changed ActorCell.ReceiveMessage method to be protected and virtual #3300
Conversation
|
Can you share with some related performance benchmarks to track changes? |
|
@Horusiath sure thing - I'll pull down the NBench numbers now and compare to the latest dev. This would impact all non-Router actors potentially, since the compiler can't inline |
|
| Metric | Units | Max | Average | Min | StdDev |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 177.00 | 156.08 | 154.00 | 6.30 |
| TotalCollections [Gen1] | collections | 76.00 | 66.38 | 54.00 | 7.53 |
| TotalCollections [Gen2] | collections | 23.00 | 3.00 | 1.00 | 6.06 |
| [Counter] MessageReceived | operations | 30,000,000.00 | 30,000,000.00 | 30,000,000.00 | 0.00 |
Per-second Totals
| Metric | Units / s | Max / s | Average / s | Min / s | StdDev / s |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 26.81 | 24.24 | 20.17 | 2.19 |
| TotalCollections [Gen1] | collections | 13.14 | 10.37 | 8.03 | 1.87 |
| TotalCollections [Gen2] | collections | 2.62 | 0.40 | 0.15 | 0.68 |
| [Counter] MessageReceived | operations | 5,190,696.77 | 4,673,513.36 | 3,419,457.34 | 515,804.42 |
UntypedActor throughput with this change
Totals
| Metric | Units | Max | Average | Min | StdDev |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 179.00 | 161.69 | 155.00 | 9.94 |
| TotalCollections [Gen1] | collections | 77.00 | 64.15 | 54.00 | 9.17 |
| TotalCollections [Gen2] | collections | 25.00 | 7.92 | 1.00 | 10.10 |
| [Counter] MessageReceived | operations | 30,000,000.00 | 30,000,000.00 | 30,000,000.00 | 0.00 |
Per-second Totals
| Metric | Units / s | Max / s | Average / s | Min / s | StdDev / s |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 27.56 | 23.43 | 20.69 | 2.22 |
| TotalCollections [Gen1] | collections | 12.03 | 9.28 | 7.41 | 1.41 |
| TotalCollections [Gen2] | collections | 3.15 | 1.02 | 0.14 | 1.24 |
| [Counter] MessageReceived | operations | 5,333,699.44 | 4,370,527.77 | 3,547,353.74 | 572,698.39 |
|
N.B., |
|
| Metric | Units | Max | Average | Min | StdDev |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 178.00 | 161.92 | 155.00 | 8.43 |
| TotalCollections [Gen1] | collections | 76.00 | 69.85 | 56.00 | 7.28 |
| TotalCollections [Gen2] | collections | 24.00 | 8.77 | 1.00 | 8.30 |
| [Counter] MessageReceived | operations | 30,000,000.00 | 30,000,000.00 | 30,000,000.00 | 0.00 |
Per-second Totals
| Metric | Units / s | Max / s | Average / s | Min / s | StdDev / s |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 24.57 | 21.60 | 18.08 | 2.00 |
| TotalCollections [Gen1] | collections | 11.25 | 9.35 | 7.57 | 1.49 |
| TotalCollections [Gen2] | collections | 2.68 | 1.07 | 0.14 | 0.89 |
| [Counter] MessageReceived | operations | 4,755,540.72 | 4,023,773.24 | 3,081,462.12 | 515,596.24 |
UntypedActor Throughput on dev
Totals
| Metric | Units | Max | Average | Min | StdDev |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 162.00 | 156.38 | 155.00 | 1.85 |
| TotalCollections [Gen1] | collections | 73.00 | 62.23 | 55.00 | 6.57 |
| TotalCollections [Gen2] | collections | 9.00 | 2.38 | 1.00 | 2.47 |
| [Counter] MessageReceived | operations | 30,000,000.00 | 30,000,000.00 | 30,000,000.00 | 0.00 |
Per-second Totals
| Metric | Units / s | Max / s | Average / s | Min / s | StdDev / s |
|---|---|---|---|---|---|
| TotalCollections [Gen0] | collections | 27.08 | 22.36 | 20.45 | 1.73 |
| TotalCollections [Gen1] | collections | 12.41 | 8.94 | 7.26 | 1.51 |
| TotalCollections [Gen2] | collections | 1.17 | 0.33 | 0.13 | 0.33 |
| [Counter] MessageReceived | operations | 5,242,170.27 | 4,290,378.12 | 3,910,750.47 | 351,846.32 |
|
The The TL;DR; it looks to me like this change doesn't have an effective impact on performance. The compiler probably wasn't inlining this method before, probably because the underlying base actor implementation that gets called inside the Either way, I think this change is probably safe in terms of its performance impact on Akka.NET message processing throughput. |
|
@Horusiath before we do this change though, let me do some testing locally today to ensure that this is the only API change necessary to introduce this instrumentation. I'd like to do this in one bite :p |
|
Ok, can verify that this change gives me what I need to instrument all actor message processing. Good to go. |
API change and that may also have some performance impact (
virtualmethods can't be inlined by the compiler).Rationale for this change is that it allows developers who are working on aspect-oriented add-ons for Akka.NET, such as yours truly, to be able to decorate 100% of actors with instrumentation and other goodies without having to have the user consume a custom actor base class or anything else that makes "infrastructure" a foreground concern. Also makes it possible to instrument built-in
/systemactors, which is part of my goal.Using a custom
ActorCellallows me to keep most of this stuff out of end-user code. However, at the moment there isn't a way for me to inject instrumentation at the time of processing a message, aside from doing it inside a customIMessageQueueimplementation used inside theMailboxof the actor. I don't like theIMessageQueueapproach namely because things like accessing a distributing tracing engine or a monitoring system seems like concerns of the actor, rather than its message-ordering infrastructure. Edit: there's also relevant pieces of information I can't access from within theIMessageQueue, such as the implementation type of the actor processing the messageAnyway, if there aren't any major objections or horrible performance implications (I could try to get cute with IL injection or something else) I think this would be a good way to provide some extensibility for this case.