Menu
Windows 8.1. IIS 8.5. SignalR versions:
<package id="Microsoft.AspNet.SignalR" version="2.1.2" targetFramework="net451" />
<package id="Microsoft.AspNet.SignalR.Core" version="2.1.2" targetFramework="net451" />
<package id="Microsoft.AspNet.SignalR.JS" version="2.1.2" targetFramework="net451" />
<package id="Microsoft.AspNet.SignalR.SystemWeb" version="2.1.2" targetFramework="net451" />
Whenever I rebuild my project/solution, IIS spikes to max CPU usage and I cannot reload my page. I checked procmon.exe and it reports an enormous amount (>20 000/s) of "RegOpenKey/RegQueryKey" operations like these ones:
Date & Time: 19.11.2014 10:47:20
Event Class: Registry
Operation: RegQueryKey
Result: SUCCESS
Path: HKLM
TID: 23272
Duration: 0.0000059
Query: HandleTags
HandleTags: 0x0
Date & Time: 19.11.2014 10:47:20
Event Class: Registry
Operation: RegOpenKey
Result: REPARSE
Path: HKLM\SYSTEM\CurrentControlSet\Services\SignalR\Performance
TID: 23272
Duration: 0.0000121
Desired Access: Read
Date & Time: 19.11.2014 10:47:20
Event Class: Registry
Operation: RegOpenKey
Result: NAME NOT FOUND
Path: HKLM\System\CurrentControlSet\Services\SignalR\Performance
TID: 23272
Duration: 0.0000062
Desired Access: Read
These are the steps I use to reproduce this issue:
I am experiencing this in IIS Express as well. Normally I resolve this by killing the IIS Worker process and reloading. Is this a permissions issue? Currently the application pool runs under my local user, but I have tried Application Pool Identity with the same results. What should be in "HKLM\System\CurrentControlSet\Services\SignalR\Performance"? Currently there is no such registry key on my machine.
422
This behavior is by design. When a user attempts to navigate away from a page with an active SignalR connection, the SignalR client will then make a best-effort attempt to notify the server that the client connection will be stopped.
SignalR servers don't know if the client is dead or not and they rely on notification from the underlying websocket for connection failures, that is, the OnClose callback. One solution to this problem is to configure IIS websockets to do the ping/pong for you.
To quickly eliminate IIS as the source of the hang, check: "Http Service Request Queues\CurrentQueueSize" counter. If its 0, IIS is having no problems dequeueing requests. "W3WP_W3SVC\Active Threads" counter. This will almost always be 0, or 1 because IIS threads almost never block.
This error is commonly seen if code references SignalR objects before the connection is started. The wireup for handlers and the like that will call methods defined on the server must be added after the connection completes. Note that the call to Start is asynchronous, so code after the call may be executed before it completes.
I have not seen this behavior before. Are the 20,000/s "RegOpenKey/RegQueryKey" operations lasting from 2-3 minutes continuously? Are all of these operations accessing the "HKLM\System\CurrentControlSet\Services\SignalR\Performance" path?
SignalR is designed to stop further loading of performance counters after any performance counter fails to load.
Perhaps installing the SignalR performance counters will resolve your issue. This will create HKLM\System\CurrentControlSet\Services\SignalR\Performance.
You will have to ensure that your application pool runs under a user in the "Performance Monitor Users" group.
80
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
