iis 7 - SignalR serverSentEvents on Windows Server 2008 with IIS 7 POST request taking too much time to complete

Question

I'm using SignalR 2.0.0-beta2 and it's behaving strangely in production environment where an ASP.NET MVC 5 [ .NET Framework 4.5 ] app is installed on Windows Server 2008 with IIS 7. The AppPool is in Integrated Mode and only has this app.

The GET request made by SignalR takes only 60 ms:

http://mysite.org.br/signalr/negotiate?clientProtocol=1.3&_=1374377239338

The problem happens with the POST request that takes forever. In the most recent test right now it took incredible 3m 1s:

http://mysite.org.br/signalr/send?transport=serverSentEvents&connectionToken=Lp%2BGdI6jVTLPrQ3ZGJ065F9GrMbKYWNmgrtKPZz%2BCUYAsxrqP7hyAMPr%2Bg1E3IRY%2F0brzXVanumPy7NPCFOlcXTRrJssFD2EEoxd6fWhAVEUSfIj

When this intermittent problem happens it generally takes more than 40 seconds to complete the request.

Testing it with Firefox 22 and Firebug... if I disable browser cache, it runs smoothly, that is, there's no delay it the POST request. Otherwise, when I enable browser cache, it delays again the POST request.

Using Google Chrome 28 the POST sits there with a pending status.

If I recycle the AppPool, then the POST request takes only 203 ms. The only modification I did to this specific AppPool was that I set Idle Time-out (minutes) = 0, that is, I'd like to avoid recycling the AppPool.

Looking at Process Explorer I see that w3wp.exe has 177.300 KB (Private Bytes) and 211.900 (Working Set) and CPU is 0 right now.

Here's SignalR log information taken from Firebug console:

[00:27:20 GMT-0300] SignalR: Negotiating with '/signalr/negotiate?clientProtocol=1.3'.
Signal...FCU9MU1 (line 1)
GET http://mysiste.org.br/signalr/negotiate?clientProtocol=1.3&_=1374377239338 200 OK 62ms  
js?v=K...xUBM641 (line 1)
[00:27:20 GMT-0300] SignalR: Attempting to connect to SSE endpoint 'http://mysiste.org.br/signalr/connect?transport=serverSentEvents&connectionToken=Lp%2BGdI6jVTLPrQ3ZGJ065F9GrMbKYWNmgrtKPZz%2BCUYAsxrqP7hyAMPr%2Bg1E3IRY%2F0brzXVanumPy7NPCFOlcXTRrJssFD2EEoxd6fWhAVEUSfIj&connectionData=%5B%7B%22name%22%3A%22assessmenthub%22%7D%5D&tid=5'
Signal...FCU9MU1 (line 1)
[00:27:20 GMT-0300] SignalR: EventSource connected
Signal...FCU9MU1 (line 1)
[00:27:20 GMT-0300] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000
Signal...FCU9MU1 (line 1)
POST http://mysiste.org.br/signalr/send?transport=s...F0brzXVanumPy7NPCFOlcXTRrJssFD2EEoxd6fWhAVEUSfIj 200 OK 3m 1s 
js?v=K...xUBM641 (line 1)
[00:39:12 GMT-0300] SignalR: EventSource readyState: 0
Signal...FCU9MU1 (line 1)
[00:39:12 GMT-0300] SignalR: EventSource reconnecting due to the server connection ending
Signal...FCU9MU1 (line 1)
[00:39:14 GMT-0300] SignalR: EventSource calling close()
Signal...FCU9MU1 (line 1)
[00:39:14 GMT-0300] SignalR: serverSentEvents reconnecting
Signal...FCU9MU1 (line 1)
[00:39:14 GMT-0300] SignalR: Attempting to connect to SSE endpoint 'http://mysiste.org.br/signalr/reconnect?transport=serverSentEvents&connectionToken=Lp%2BGdI6jVTLPrQ3ZGJ065F9GrMbKYWNmgrtKPZz%2BCUYAsxrqP7hyAMPr%2Bg1E3IRY%2F0brzXVanumPy7NPCFOlcXTRrJssFD2EEoxd6fWhAVEUSfIj&connectionData=%5B%7B%22name%22%3A%22assessmenthub%22%7D%5D&messageId=d-k%2C0%7Cx%2C0%7Cy%2C1%7Cz%2C0&tid=5'
Signal...FCU9MU1 (line 1)
[00:39:44 GMT-0300] SignalR: Couldn't reconnect within the configured timeout (30000ms), disconnecting.
Signal...FCU9MU1 (line 1)
[00:39:44 GMT-0300] SignalR: SignalR: Stopping connection.

My Web.config has these settings:

<system.web>
.
.
.
    <sessionState mode="InProc" customProvider="DefaultSessionProvider">
        <providers>
            <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" />
         </providers>
    </sessionState>
</system.web>

<system.webServer>
  <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" />
  <validation validateIntegratedModeConfiguration="false" />
  <staticContent>
    <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00" />
  </staticContent>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Windsor" />
  </modules>
  <handlers>
    <add name="AttributeRouting" path="routes.axd" verb="*" type="AttributeRouting.Web.Logging.LogRoutesHandler, AttributeRouting.Web" />
  </handlers>
  <security>
    <requestFiltering>
      <requestLimits maxQueryString="10240"></requestLimits>
    </requestFiltering>
  </security>
</system.webServer>

From the symptom looks like the response is being buffered somehow. This SignalR issue mentions AVG antivirus being the problem, but I do not have AVG antivirus installed on my client's server. It has McAfee though.

What can be causing this behavior? If you need any more info to help debug this further, please just ask and I'll do my best to provide it.

---

Note: in the meantime I reverted back to SignalR stable release 1.1.2 and everything is working fine so far.

Answer 1

Just to make this clear for everyone that might find this problem in the future:

The problem is related to SessionState used in ASP.NET. As @dfowler said:

Using session with SignalR won't work at all. It'll make all requests take the session lock and that's likely why you're seeing these problems.

So, the solution is: remove the <sessionState> config from your Web.config file and any session events you might have in your Global.asax.

<sessionState mode="InProc" customProvider="DefaultSessionProvider">
    <providers>
        <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" />
    </providers>
</sessionState>

After getting rid of it the problem was solved in my case.

---

I had to update to SignalR 2.0.0 to really fix the issue.