我有一个azure应用程序服务，运行2个示例，它利用了一个共享的azure redis缓存。大多数时候，一切都很好。但有时，我明白了 RedisTimeoutException 我的应用程序服务日志中有错误。通常情况下，写操作（setex）会有一个超时，紧接着又会有大约10个超时，这是读操作和写操作的混合（我认为，其他操作在超时操作之后排队）。
例子：

StackExchange.Redis.RedisTimeoutException: Timeout awaiting response 
(outbound=0KiB, inbound=1KiB, 5984ms elapsed, timeout is 5000ms), command=SETEX, next: GET <Key_name>,
inst: 0, qu: 0, qs: 14, aw: False, rs: ReadAsync, ws: Idle, in: 0, 
serverEndpoint: <Azure_Redis_instance>, mc: 1/1/0, mgr: 10 of 10 available, clientName: <App_service_instance>, 
IOCP: (Busy=0,Free=1000,Min=2,Max=1000), WORKER: (Busy=2,Free=32765,Min=2,Max=32767), v: 2.1.28.64774
(Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

我关注了他们异常消息中的url，并通读了他们对可能的超时原因的解释，但我不相信这些都是原因。这个副标题引起了我的注意，因为我确实看到了 qs: 14 在我上面的例外中，但是我们没有使用任何长时间运行的命令。我们只使用单个缓存项的键来设置/获取它们。
在出现这些错误期间，我使用azure门户>应用程序服务>metrics blade查看应用程序服务，我没有看到cpu时间、内存工作集或连接（在应用程序服务的任一示例上）出现任何峰值。我还检查了redis缓存示例，没有发现任何内存或cpu使用的峰值。
我不知道下一步该做什么。如：
你会尝试他们的建议使用一个connectionmultiplexer对象池来避免操作在一个缓慢的操作后面排队吗(我宁愿找出它为什么慢）
我是否忽略了另一个关键的性能指标？
我看不出有什么解释 mc: 1/1/0 ，这是什么意思？