2013-07-21 2 views
3

Я использую SignalR 2.0.0-beta2 и это странно ведет себя в производственной среде, где ASP.NET MVC 5 [.NET Framework 4.5] приложение устанавливается на Windows Server 2008 с IIS 7. AppPool находится в интегрированном режиме и имеет только это приложение.SignalR serverSentEvents на Windows Server 2008 с IIS 7 запрос POST занимает слишком много времени, чтобы закончить

GET запрос сделан SignalR занимает всего 60 мс:

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

Проблема происходит с POST запроса, который принимает навсегда. В самом последнем тесте прямо сейчас потребовалось невероятное 3m 1s:

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

Когда эта неустойчивая проблема происходит, как правило, занимает больше, чем 40 секунд для выполнения запроса.

Тестирование его Firefox 22 и Firebug ... если отключить кэш браузера, она проходит гладко, то есть, нет никакой задержки его POST запроса. В противном случае, когда я включаю кеш браузера, он снова задерживает запрос POST.

Google Chrome 28 POST находится там, где находится на рассмотрении.

Если я рециркулировать AppPool, то POST запрос занимает всего 203 мс. Единственная модификация, которую я сделал с этим конкретным AppPool, заключалась в том, что я установил Idle Time-out (minutes) = 0, то есть я бы хотел избежать утилизации AppPool.

Глядя на Process Explorer я вижу, что w3wp.exe имеет 177.300 KB (Private Bytes) и 211.900 (Working Set) и CPU является 0 прямо сейчас.

Вот SignalR информация взята из журнала Firebug консоли:

[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 issue упоминается антивирус AVG, но у меня нет антивируса AVG, установленного на сервере моего клиента. Он имеет McAfee.

Что может быть причиной такого поведения? Если вам нужна дополнительная информация, чтобы помочь отладить это дальше, просто спросите, и я сделаю все возможное, чтобы предоставить ее.


Примечание: в то же время я вернулся назад к SignalR стабильной 1.1.2 релиз и все работает нормально до сих пор.

+0

Вы используете сеанс? – davidfowl

+0

@dfowler: проверьте обновленные настройки 'Web.config' с информацией' sessionState', если это то, что вы подразумеваете под 'session'. –

+1

Использование сеанса с SignalR не будет работать вообще. Это заставит все запросы занять блокировку сеанса, и, скорее всего, вы видите эти проблемы. – davidfowl

ответ

4

Просто, чтобы сделать это ясно для всех, что могли бы найти эту проблему в будущем:

Проблема связана с SessionState используется в ASP.NET. Как @dfowler сказал:

Использование сеанса с SignalR не будет работать вообще. Он сделает все запросы , чтобы заблокировать сеанс, и это, вероятно, связано с тем, что вы видите эти проблемы .

Итак, решение: удалить <sessionState> конфигурации из вашего Web.config файла и любых сессионных событий, которые вы могли бы иметь в своем 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> 

После устранения этой проблемы проблема была решена в моем случае.


мне пришлось обновить до SignalR 2.0.0 действительно решить проблему.

 Смежные вопросы

  • Нет связанных вопросов^_^