Aspnetcore: Add EventSource/EventCounter tracing and metrics for Razor

[anurse]

Some events listed below. The goal is to add events that will help users solve problems so if these aren't going to do that job, feel free to suggest/discuss others!

• Microsoft-AspNetCore-Razor EventSource
  
  
  
  • ParseStart event - Triggered when Razor parsing begins
  
  
  • ParseStop event - Triggered when Razor parsing ends
  
  
  • ParseFailure event - Triggered when an error in parsing occurs.
  
  
  • ParseDuration counter - Measures duration of Razor parsing
  
  
  • Would it be worth having separate "Parse" and "CodeGen" events or just one all-up "Parse&CodeGen" event?
  
  

See https://gist.github.com/anurse/af1859663ac91c6cf69c820cebe92303 for some guidance on adding EventSources and EventCounters to ASP.NET projects.

[NTaylorMullen]

Would it be worth having separate "Parse" and "CodeGen" events or just one all-up "Parse&CodeGen" event?

Not valuable to separate.

[anurse]

Cool, thanks for clarifying. Let's just call the whole thing Parse then since that's how most users would understand it.

[rynowak]

Not valuable to separate.

Could not possibly disagree more. We should make this stuff granular where possible.

---

Part of this needs to go into MVC - as 'a view is compiling' - but these detailed events are still good to have in Razor - if anything for analyzing inner loop perf.

[anurse]

Ok, if these actually take the form of separate phases, I would definitely agree with @rynowak . I wasn't sure how much has changed since I last saw Razor code :P. I'll leave it to you guys to work out specifically what kinds of events are most appropriate. Please feel free to include me on any PRs for feedback on the EventSource patterns.

[NTaylorMullen]

Could not possibly disagree more. We should make this stuff granular where possible.

How would this "help users solve problems"? They have 0 control over the parsing phase since it's not public. I could see an argument to measure intermediate/code gen phases since that's extensible but not the syntax tree parsing phase.

[rynowak]

"help users solve problems"

I don't buy the premise - that's not the purpose of eventsource.

This helps US visualize performance and this is on the critical path for inner loop. Even if all this does is confirm that it's fast, which we know it is, we can still use that data to provide context.

[anurse]

The goal is that it's for both of those purposes. It is valuable for us to visualize issues (performance or otherwise) but also for users to solve problems. So in this case, if it's got significant value for us, it's worth adding even if we don't see users having a use for it, and vice-versa.

[rynowak]

@pranavkm @NTaylorMullen can you think on this and come up with a proposal for eventing between Razor and MVC?

[mkArtakMSFT]

@DamianEdwards, should we try to do this now or we can delay it? /cc: @rynowak

[danroth27]

Confirmed that this effort is being pushed out.