Three new Videos on using PerfView’s Event View (And Using it in conjunction with System.Diagnostics.Tracing.EventSource)


 

I have just posted the following 3 videos to the my Channel 9 PerfView Tutorial Series.

If you are not already comforable with PerfView’s event viewer, I do recommend you take a look.   The event viewer lets you see ETW data in its rawest form (as a time ordered list of events, where each event can have a event-specific payload).    It is particularly useful for just answer questions like ‘what processes were running?  What DLLs were loaded?  What request URLs were serviced?    It is also VERY useful in getting you the infomration need to ‘home in’ on a particular request and get the time range and thread information needed to isolate the performance JUST THAT REQUEST from everything else happening on the server. 

 

Comments (7)

  1. Lenin says:

    Nice videos. Keep the good stuff rolling.

  2. Tom Krueger says:

    What is the fine print when adding an EventSource? Is the code required for reading/interpreting an .etl file? Does it influence the registry (as PerformanceCounter do)? Do I need admin rights upon first use?

    Sounds good otherwise!

    Tom

  3. The 'fine print' for actually CODING with Evensources, is pretty short (practically non-existant).   EventSources do not influence the registry in any way (better than PerfCounters in that respect).  They work without admin rights, and in particular work fin in Win8 AppContainers.   Thus they act like 'normal' code.  

    However there is 'fine print' on the controling/reading side when using EventSources to generate ETW logs.   ETW (Because it is system wide), does require Admin priviliges to turn on.   This is perhaps the biggest stumbling block.  The format for reading the ETL file is an ETW standard, and thus does not 'know' anything about EventSources, however tools like PerfView (and soon WPA), will be able to parse them into something human readable.   You can do more by making a custom viewer either by extending PerfView (see its help for more), or using the TraceEvent library (at bcl.codeplex.com/wikipage).

    Finally, if your goal is for your Win8 app to be 'self logging' (send its data back to you over the web), using ETW is not appropriate (it is machine wide and needs Admin).   For that you shoudl be using the System.Diagnostics.Tracing.EventListener class instead of the ETW to 'act as a sink for your EventSource.  This class will get called back on every event, and has the same controlling capabilities as ETW has.   This allow you to then send the events back over the web, or log them to a file, or to a database etc.  

  4. Hernan says:

    Hi Vance, I don't know if you monitor some forum so I post the question here. Do you recommend any strategy for low latency EventListeners like high I/O with files, DBs, etc ?

    Do you think that trying to make them execute in a separate thread (async mode) will make any conflict with the current EventSource/Listener model?

    Thanks

  5. It sounds like you are not using ETW as your eventing stream and writing your own EventListener for your EventSources.   This is fine, but as you may have realized Eventlisteners today simply get called when EventSources call 'WriteEvent'   Thus you can have problems if you are logging to high latency target(e.g. the network, the disk tends to be buffered enough so that it is not an issue), AND your EventSources are in high/volume perf-critical areas.   In cases such having a separate thread MAY be useful.   THere are a few caveats however

    1) If you generate events faster than your target can absorb them, then you WILL lose events eventually.   Thus what the separate thread only 'solves' the problem of keeping EventSource logging latency under control by dropping packets.   Are you willing to drop events?

    2) If you are just logging to a local disk, it is likley that the buffering that the OS does ALREADY is more than sufficient to keep the latency of the average EventSource logging message under control.  (You can easly set up an experiment and use PerfView to confirm).    Databases and Network files are less likely to work, but you can measure an see for sure.   If you wanted to keep EventSource logging REALLY low (< 1usec range) you probably do need a memory buffer with a worker thread to drain the buffer.  

    My guess is that if you just want to log to a file, you need not bother with async, but other targets could easily benefit.  

  6. Jep says:

    Where or how does one get help?  I am following your tutorial on Channel 9 msdn.   After I run the tutorial.exe, I do not get the pop up window where I should be able to click on process.  

    jeplike@yahoo.com

  7. Since the time the video was created PerfView has changed so that it does not automatically open the CPU Stacks view.    After collecting the data, a PerfViewData.etl file should be present in the main viewer's file tree on the left.   If it is not already open, open it by double clicking on it, and again double click in the 'CPU Stacks's view.   This will make the process chooser dialog box come up and you can follow along with the rest of the video.