Temos várias funções da Web e de trabalho no Azure conectando-se ao cache Redis do Azure por meio da biblioteca StackExchange.Redis e estamos recebendo tempos limite regulares que estão fazendo com que nossa solução de ponta a ponta seja interrompida. Um exemplo de um deles está abaixo:

System.TimeoutException: Tempo limite executando fluxo GET: 459, inst: 4, mgr: Inativo, fila: 12, qu = 0, qs = 12, qc = 0, wr = 0/0, em = 65536/0 no StackExchange.Redis .ConnectionMultiplexer.ExecuteSyncImpl [T] (mensagem de mensagem ResultProcessor1 processor, ServerEndPoint server) in c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 1785 at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor1 processador, servidor ServerEndPoint) em c: \ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisBase.cs: linha 79 em StackExchange.Redis.RedisDatabase.StringGet (chave RedisKey, sinalizadores CommandFlags) em c: \ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisDatabase.cs: linha 1346 em OptiRTC.Cache.RedisCacheActions. <> C__DisplayClass41.<Get>b__3() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 104 at Polly.Retry.RetryPolicy.Implementation(Action action, IEnumerable1 shouldRetryPredicates, Func`1 policyStateFactory) em OptiRTC.Cache.RedisCacheActions.Get [T] (Chave de cadeia, Boolean allowDirtyRead) em c: \ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheActions.cs: linha 107 em OptiRTC.CacheAccess.RedisCache. .d__e4.MoveNext () em c: \ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheAccess.cs: linha 1196; Evento TraceSource 'WaWorkerHost.exe'

Todos os tempos limites têm números de fila e qs diferentes, mas o restante das mensagens é consistente. Essas chamadas StringGet são diferentes chaves no cache. Em cada um de nossos serviços, usamos uma classe de acesso ao cache de singleton com um único ConnectionMultiplexer registrado com nosso contêiner IoC na inicialização da Web ou da função de trabalhador:

        container.RegisterInstance<ICacheAccess>(cacheAccess);

Em nossa implementação do ICacheAccess, estamos criando o multiplexador da seguinte maneira:

            ConfigurationOptions options = new ConfigurationOptions();
            options.EndPoints.Add(serverAddress);
            options.Ssl = true;
            options.Password = accessKey;                    
            options.ConnectTimeout = 1000;
            options.SyncTimeout = 2500;

            redis = ConnectionMultiplexer.Connect(options);

onde o objeto redis é usado em toda a instância. Temos cerca de 20 instâncias de funções da Web e de trabalho conectadas ao cache por meio dessa implementação do ICacheAccess, mas o console de gerenciamento mostra uma média de 200 conexões simultâneas ao cache.

Eu já vi outras postagens que fazem referência usando a versão 1.0.333 do StackExchange.Redis, o que estamos fazendo via NuGet, mas quando observo a versão real da referência StackExchange.Redis.dll adicionada, ela mostra 1.0.316.0. Tentamos adicionar e remover a referência do NuGet, além de incluí-la em um novo projeto, e sempre obtemos a discrepância de versão.

Qualquer insight seria apreciado. Obrigado.

Informação adicional:

Atualizamos para 1.0.371. Temos dois serviços que cada um acessa o mesmo objeto de cache em intervalos diferentes, um para editar e ocasionalmente ler e outro que lê esse objeto várias vezes por segundo. Ambos os serviços são implantados com o mesmo código de cache e a versão da biblioteca StackExchange.Redis. Quase nunca vejo tempos limite no serviço que edita o objeto, mas recebo tempos limite entre 50 e 75% do tempo nos serviços que o lêem. Os tempos limite têm o mesmo formato que o indicado acima e continuam ocorrendo após a quebra da chamada db.StringGet em um bloco de repetição Polly que lida com RedisException e System.TimeoutException e tenta novamente uma vez após 500 ms.

Entramos em contato com a Microsoft sobre esse problema e eles confirmam que não veem nada nos logs do Redis que indiquem um problema no lado do serviço Redis. Nossa% de perda de cache é extremamente baixa no servidor Redis, mas continuamos a receber esses tempos limite, o que prejudica substancialmente a funcionalidade do aplicativo.

Em resposta aos comentários, sim, sempre temos um número em qs e nunca em qc. Sempre temos um número na primeira parte da entrada e nunca na segunda.

Ainda mais informações adicionais:

Quando executo um serviço com menos instâncias em uma CPU mais alta, recebo significativamente mais desses erros de tempo limite do que quando as instâncias estão sendo executadas em CPUs mais baixas. Mais especificamente, peguei alguns números de nossos serviços esta manhã. Quando eles estavam rodando com cerca de 30% da CPU, vi muito poucos problemas de tempo limite - apenas 42 em 30 minutos. Quando removi metade das instâncias e elas começaram a rodar em torno de 60 a 65% da CPU, a taxa aumentou 10 vezes para 536 em 30 minutos.