Cannot record new actions after DOM is loaded with SignalR - only shows after page reload

[Saibamen]

MiniProfiler Alpha 7, .Net Core 1.1, VS 15.3, Win10

TL;DR: Current actions profiling from SignalR shows after page reload - not in real time.

I added few Start() methods to SignalR hub code and I see a weird bug.
First connection to site gives me only one profile, but when I refresh (F5 or entering this same site again) page - SignalR profiling appears magically...

When full page (DOM) is loaded, MiniProfiler cannot record new actions (from SignalR). Tip: page isn't reloaded when new SignalR action is submitted. We stay at one HTTP request.

Current profiler for actions with SignalR (Start(), Stop() functions) shows after page reload - not in real time.

First connection:

	duration (ms)
MiniProfiler	186.7
Controller: User.Index	6.1
Find: Index	3474.7
Render: /Views/User/Index.cshtml	941.5
Find: Components/CreateRoom/Default	489.7
Render: /Views/Shared/Components/CreateRoom/D...	166.3
Find: Components/CreatePrivateConversation/De...	68.7
Render: /Views/Shared/Components/CreatePrivat...	7.5
Find: Components/BrowseRooms/Default	73.1
Render: /Views/Shared/Components/BrowseRooms/...	12.4
Find: _DeleteModalPartial	62.5
Render: /Views/Shared/_DeleteModalPartial.csh...	3.1
Find: _LeftSidebarPartial	62.5
Render: /Views/Shared/_LeftSidebarPartial.csh...	31.4
Find: _RightSidebarPartial	50.5
Render: /Views/Shared/_RightSidebarPartial.cs...	3.4
client event	duration (ms)
--	--
Response	17.0
Dom Content Loaded Event	6.0
Load Event	11.0
Dom Complete

After refresh:

	duration (ms)
MiniProfiler	53.7
Controller: User.Index	2.7
Render: /Views/User/Index.cshtml	16.2
client event	duration (ms)
--	--
Response	3.0
Dom Content Loaded Event	7.0
Load Event	13.0
Dom Complete

And my SignalR action profiler from first connection (only appears after refresh):

	duration (ms)	sql (ms)
GetRooms	30.0	13.5 (2)

[NickCraver]

I think I understand here (not intimately familiar with SignalR), you're saying server-side events are happening but all over the SignalR pipeline and the browser is simply unaware? So MiniProfiler is working and recording, but the client isn't fetching them for display?

...or am I not understanding the issue?

[Saibamen]

Yes, you're correct

[NickCraver]

@davidfowl I haven't dug into 2.0 yet, is there a reasonable hook point to look for/observe here in a new MiniProfiler.SignalR package that'll pull results from the server? I'm very curious on how you think we should handle SignalR apps in general...would like to do it proper.

[davidfowl]

What version of SignalR is this (the unsupported one most likely since the .NET Core version only released an alpha last week)?

The historically, SignalR has had a hub pipeline for plugging into the execution pipeline but that's currently not supported in the current alpha (see aspnet/SignalR#871). This might be a case for it assuming that's what you want to record.

[NickCraver]

@davidfowl I'm okay only supporting 2.x and up here - the issue isn't profiling SignalR itself (though we'll likely add some bits there later), but rather communicating to the client there are MiniProfilers available to display (they're already there, building up).

Today, when a request is made, a MiniProfiler ID guid is in the <script> tag, or if it's an AJAX request we look for a header that contains them. When we see them, we turn around and hit the server to get them. This happens when a .Stop() is called in MiniProfiler, so I could expose an event handler there to call something in SignalR to communicate with a client something happened for them. I'm unsure of the semantics here at the various layers though, since the mass-user case of SignalR exists, unlike a typical single-user/single-connection web request.

Perhaps on-stop if the request/work is caused by SignalR we call and publish to the client that caused it, if they are a valid consumer of the profiler? Again, unsure of mass-consumer cases, we'd only want to target single-user scenarios here most likely.

I imagine Glimpse would have the same issues, has any thought been given to how to deliver meta information about a workload to clients general? I'd assume there are plug points but it'll be a while before time allows digging in, pointer to the best place to start looking would be much appreciated!

[NickCraver]

@davidfowl Just checking - is there any change here on the SignalR side here? A plug point you'd recommend for MiniProfiler IDs sending to the client once a request/handler is complete?

I haven't gotten any more requests for this, but if it was reasonable to add I think it'd still be a good thing. If no plug points are intended there I'm also happy to close it out with a reason for anyone finding this later.