如何在Azure redis緩存中修復此超時異常？

Question

我們有一個Web應用程序，它使用Microsoft.Web.Redis.RedisSessionStateProvider作為會話狀態提供程序。 直到最近我們才突然發現應用程序報告了大量例外，我們對此沒有任何問題，如下所述。

該消息表明某種超時。 但我不知道如何解決這個問題。 該應用程序是Kentico CMS的一個實例，我們沒有以任何方式定制其會話緩存機制。

主要例外：

信息：

拋出了類型'System.Web.HttpException'的異常。

堆棧跟蹤：

at System.Web.HttpAsyncResult.End() 
at System.Web.HttpApplication.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) 

內部異常：

信息：

超時執行EVAL，inst：1，mgr：無效，錯誤：從不，隊列：0，qu：0，qs：0，qc：0，wr：0，wq：0，in：0，ar：0，IOCP： （Busy = 0，Free = 1000，Min = 2，Max = 1000），WORKER :( Busy = 3，Free = 32764，Min = 2，Max = 32767），clientName：KSCOMAZUATWEB2

堆棧跟蹤：

at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor`1 processor, ServerEndPoint server) in c:\TeamCity\buildAgent\work\3ae0647004edff78\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 1927 
at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor`1 processor, ServerEndPoint server) in c:\TeamCity\buildAgent\work\3ae0647004edff78\StackExchange.Redis\StackExchange\Redis\RedisBase.cs:line 80 
at StackExchange.Redis.RedisDatabase.ScriptEvaluate(String script, RedisKey[] keys, RedisValue[] values, CommandFlags flags) in c:\TeamCity\buildAgent\work\3ae0647004edff78\StackExchange.Redis\StackExchange\Redis\RedisDatabase.cs:line 866 
at Microsoft.Web.Redis.StackExchangeClientConnection.<>c__DisplayClass4.<Eval>b__3() in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\Shared\StackExchangeClientConnection.cs:line 113 
at Microsoft.Web.Redis.StackExchangeClientConnection.RetryForScriptNotFound(Func`1 redisOperation) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\Shared\StackExchangeClientConnection.cs:line 129 
at Microsoft.Web.Redis.StackExchangeClientConnection.RetryLogic(Func`1 redisOperation) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\Shared\StackExchangeClientConnection.cs:line 155 
at Microsoft.Web.Redis.StackExchangeClientConnection.Eval(String script, String[] keyArgs, Object[] valueArgs) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\Shared\StackExchangeClientConnection.cs:line 113 
at Microsoft.Web.Redis.RedisConnectionWrapper.TryTakeWriteLockAndGetData(DateTime lockTime, Int32 lockTimeout, Object& lockId, ISessionStateItemCollection& data, Int32& sessionTimeout) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\RedisSessionStateProvider\RedisConnectionWrapper.cs:line 182 
at Microsoft.Web.Redis.RedisSessionStateProvider.GetItemFromSessionStore(Boolean isWriteLockRequired, HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actions) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\RedisSessionStateProvider\RedisSessionStateProvider.cs:line 272 
at Microsoft.Web.Redis.RedisSessionStateProvider.GetItemExclusive(HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actions) in d:\TeamCityBuildAgent\work\f55792526e6d9089\src\RedisSessionStateProvider\RedisSessionStateProvider.cs:line 190 
at System.Web.SessionState.SessionStateModule.GetSessionStateItem() 
at System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state) 

Answer 1

在遇到相同的問題並閱讀了有關設置最小和最大線程值等的各種帖子后，發現問題出在訂閱層上。

C1 basic（£35 / GBP mth）擁有1gb緩存，1000個並發連接，這與C1標准層（£95GBP / Mth）完全相同。 這是一個很自然的假設，當你只需要幾MB的緩存並且在任何時候只有50個並發會話處於活動狀態時，那就是C！ 基本就足夠了，如果不是矯枉過正的話。

如果您的網站上有10個或更少的並發用戶，那么差異似乎是C1 Basic的工作原理。 公平地說，在細則中提到基本只適用於開發和測試環境。

Answer 2

我只是在客戶端站點上完成此操作，幫助我的是將其添加到提供者的連接字符串中：

throwOnError="true" retryTimeoutInMilliseconds="500"

我所學到的有時會出現延遲問題，如果它解析得不夠快，則默認只是“退出”。 所以添加這個允許它繼續重試。

你的字符串可能如下所示

<add name="MySessionStateStore" throwOnError="true" retryTimeoutInMilliseconds="500" type="Microsoft.Web.Redis.RedisSessionStateProvider" host="mysite-prod.redis.cache.windows.net" accessKey="mykey" ssl="true" />