带有IIS 7 POST请求的Windows Server 2008上的SignalR serverSentEvents需要花费太多时间才能完成 [英] SignalR serverSentEvents on Windows Server 2008 with IIS 7 POST request taking too much time to complete

问题描述

我正在使用 SignalR 2.0.0-beta2 它在生产环境中表现奇怪，在 Windows Server 2008上安装了 ASP.NET MVC 5 [.NET Framework 4.5]应用程序， IIS 7 。 AppPool处于集成模式，只有这个应用程序。

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.

GET 请求> SignalR 只需 60 ms ：

The GET request made by SignalR takes only 60 ms:

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

问题发生在 POST 请求永远需要。在最近的测试中，它现在花了不可思议的 3m 1s ：

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

当发生这种间歇性问题时，通常需要超过 40秒 来完成请求。

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

测试它使用 Firefox 22 和Firebug ......如果我禁用浏览器缓存，它会顺利运行，也就是说，<$ c $没有延迟c> POST 请求。否则，当我启用浏览器缓存时，它会再次延迟 POST 请求。

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.

使用 Google Chrome 28 POST位于待处理状态。

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

如果我回收 AppPool ，然后 POST 请求仅需 203 ms 。
我对这个特定的 AppPool 做的唯一修改是我设置空闲超时（分钟）= 0 ，也就是说，我想避免回收AppPool。

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.

查看Process Explorer我看到 w3wp.exe 177.300 KB（私有字节）和 211.900（工作集）和 CPU 现在是 0 。

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.

这是 SignalR 从Firebug控制台获取的日志信息：

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.

我的 Web.config 具有以下设置：

<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>

从症状看起来响应正以某种方式缓冲。这个 SignalR问题提到了AVG防病毒问题，但我没有安装AVG防病毒软件在我客户的服务器上。它有 McAfee 。

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.

注意：与此同时，我又回到了SignalR稳定版1.1.2，到目前为止一切正常。

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

推荐答案

只是为将来可能会发现此问题的每个人说清楚：

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

问题与 SessionState 。正如 @dfowler 所说：

使用与SignalR的会话根本不起作用。这将使所有请求
采取会话锁定，这可能是你看到这些
问题的原因。

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.

因此，解决方案是：从 Web.config 文件和任何会话中删除< sessionState> config您可能在 Global.asax 中发生的事件。

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.

我必须更新为 SignalR 2.0.0 真正解决了这个问题。

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

这篇关于带有IIS 7 POST请求的Windows Server 2008上的SignalR serverSentEvents需要花费太多时间才能完成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！