Showing results for 
Show  only  | Search instead for 
Did you mean: 

How can I use AppMon to instrument signalr?


Microsoft has added a new feature to the ASP.NET framework called SignalR. This framework adds a connection-oriented aspect to web apps. Instead of the browser requesting content from the server, which the server responds with, the server can push an update to the browser in response to other events on the server - like a different user updating something. The canonical usage scenario for SignalR is a chat application where every browser using the web app receives posts from other users without having to refresh their browser. The posts are pushed browsers connected to Hubs. SignalR tries to use Web Sockets for this, but it degrades gracefully to Server Sent Events, Forever Frames, and JavaScript Long Polling in down level scenarios.

I am interested in knowing how long it takes my application to update all of the connected clients (in the HUB). I have read posts that suggest creating a custom sensor to instrument the server-side of a Web Socket event. Problem is, I can't find a single method to act as the entry point to start the PurePath. I believe the SignalR folks rely on features in .NET 4.5 to push updates asynchronously. SignalR is open source on GitHub so I was wondering if someone has found the class and method to instrument.



Hi Rob,

We already
discussed SignalR within R&D and indeed it is an important library for .NET
devs. Currently we have no support for it. First of all, I would encourage you to
up vote the RFE for SingalR (

Now supporting
SignalR is tricky, since there are multiple fallbacks on the protocol level
(like foreverframe, long pooling, etc.) and we have to make sure that this
does not make the PurePaths corrupt (e.g. because of a timeout). Anyway, I look
into this issue and will come back to you with results. No promises here, maybe
the outcome will be that we cannot do anything at the moment.



R&D, .NET Team



As promised, here is a more detailed answer:

First of all, I would split this into two parts:

  1. Monitoring with SingalR Performance Counters
  2. Monitoring on PurePath (PP) basis

1.Monitoring with SingalR Performance Counters The .NET agent is able to read performance

counters and SignalR has its own perfcounters. Here is a documentation about it: This gives you great visibility about the connections, etc. Of course in this case you don’t have method level visibility, therefore let’s move on:

2.Monitoring on PurePath (PP) basis

I built a sample application to see what we can monitor with the current release. The first problem I ran into was that when the clients connected via websocket then there was a single PP and every round trip from a client to the server was correlated to this PP resulting in a huge, eventually corrupted PP.

The solution for this is to exclude the ‘/signalr’ url (or if it is configured for another URL then that one…) by the sensor (and if you have an IIS agent, then you should also exclude it there). Now from this point there were no PPs created by default. What I did was that I added a custom sensor rule for my Hub methods. This way I always got a PP when a client posted something to the hub.

If you want to get a PP when a client connects/reconnects/disconnects you can also instrument the methods defined by the Hub class:

Now unfortunately that is all, which we can do at the moment. So thing like figuring out how long it takes to update all the client is not possible with this, but with the performance counters you can get information when something went wrong (e.g. Errors: Transport Total) and about the overall performance (e.g. Message Bus Messages Received Total, Message Bus Messages Received/Sec, Message Bus Messages Published/Sec, Message Bus Subscribers Current, Message Bus Subscribers Total, Message Bus ubscribers/Sec)




How can i exclude signalr requests from being monitored in Dynatrace Managed? I've tried using the new exclude web url feature but it doesn't seem to work as i expect it to.

After adding this exclusion, signalr requests are still monitored.

I've now tried muting those requests instead, but excluding them would be preferable.

Note also i've voted on the RFE -