-
-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP - InteractionProfilerGrain #345
base: master
Are you sure you want to change the base?
Conversation
namespace OrleansDashboard.Model | ||
{ | ||
[Serializable] | ||
public class GrainInteractionInfoEntry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we start to use records for that?
|
||
namespace OrleansDashboard.Implementation | ||
{ | ||
public sealed class GrainInteractionFilter : IIncomingGrainCallFilter, IOutgoingGrainCallFilter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not extend the current filter for that? Because we have some logic there that we should keep. Like custom method names and attributes to opt out from the profiler.
var info = stack.Pop(); | ||
|
||
grainInteractionProfiler ??= grainFactory.GetGrain<IInteractionProfiler>(0); | ||
await grainInteractionProfiler.Track(info); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current profiler we use batching to reduce the grain calls. I think we should use the same approach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, I added a few comments.
|
||
private string BuildGraph() | ||
{ | ||
var content = string.Join("\n ", interaction.Values.SelectMany(s => s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer not to concern the back end with front end configuration, such as colours. Could we just return pure data as JSON to the front end?
@@ -26,6 +26,8 @@ public static class ServiceCollectionExtensions | |||
{ | |||
builder.ConfigureApplicationParts(parts => parts.AddDashboardParts()); | |||
builder.ConfigureServices(services => services.AddDashboard(configurator)); | |||
builder.AddIncomingGrainCallFilter<GrainInteractionFilter>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would like a way to control (switch on/off) this profiling, as it may get slow?
Can we close this? |
I can't figure out how to do it well to store the history of calls |
Why do you want to store the history? The Dashboard is only designed to show either the present or data over the full lifetime of the silo. If you can provide a view that shows the interaction over the full lifetime it would provide value. For detailed analysis you should use telemetry anyway. |
I'd like to show who's calling whom. I hadn't thought of this as a long term storage. my case is to look for deadlocks or delays. |
Here, most likely, by storage, I mean how to collect statistics and pass them to the UI @SebastianStehle |
I think we cannot analyze single calls. This would be responsibility of new relic or application insights. We can only collect general call structure. So basically the following table: SourceGrain | SourceMethod (if possible) | TargetGrain | TargetMethod | Count | CountSuccess | CountFailed | TotalTimeNs So basically the following dictionary
|
I found an interesting side effect |
Seems I found Idea for it |
First step for #344
Filter + Grain