我们最近试图从azureredis切换到redis enterprise，不幸的是，大约一个小时后，由于性能问题，我们被迫回滚。我们正在寻求关于如何找到根本原因并继续进行的建议。这是我到目前为止所发现的，但我很高兴在必要时补充更多细节。
首先，客户端是一个使用stackexchange.redis 2.1.30版的.net framework应用程序。azure redis示例使用4个碎片，redis enterprise示例也配置为4个碎片。
当我们切换到redis enterprise时，我们会立即看到每5分钟就有几千个这样的异常：
执行get超时（5000ms），下一步：get[challenges]：：306331，inst:1，qu:0，qs:3079，aw:false，rs:readasync，ws:idle，in:0，serverendpoint:x:17142，mc:1/1/0，mgr:9/10可用，clientname:api，iocp:（忙=2，空闲=998，最小=400，最大=1000），worker:（忙=112，空闲=32655，最小=2000，最大=32767），本地cpu:4.5%，v:2.1.30.38891（请参阅本文，了解一些可能导致超时的常见客户端问题：https://stackexchange.github.io/stackexchange.redis/timeouts)
看看这个错误消息，工作线程池中似乎有很多东西（等待redis enterprise的响应），但iocp线程池中几乎没有东西（来自redis的响应等待客户端代码处理）。因此，redis方面存在某种瓶颈。
使用appinsights，我创建了繁忙工作线程（深蓝色）、繁忙io线程（红色）和cpu使用率（浅蓝色）的图表。我们看到这样的情况：

cpu从来没有真正超过20%左右，io线程只是一个小点（我认为最大值就像2个忙线程），但是工作线程有点增长，直到最后所有的事情都超时，进程重新开始。晚上7点过后，我们决定回滚到azureredis，所以在这一点上一切都很好。所以，一切都表明redis是某种瓶颈。那么，让我们看看redis的一面。
在此期间，redis报告的cpu使用率最高约为5%。传入流量最高约为1.4mb/s，传出流量最高约为9.5mb/s。每秒操作数约为4k。这段时间的延迟是0.05毫秒，最慢的是15毫秒左右。换句话说，redis企业节点几乎不费吹灰之力，而且很容易跟上发送给它的流量。事实上，集群中还有4个节点甚至没有被使用，因为redis甚至不认为需要向其他节点发送任何东西。雷迪斯基本上只是打哈欠。
从这里开始，我想可能有网络带宽限制。我们所有的虚拟机都配置为加速联网，我们应该有10gig连接到这些机器。我决定在客户端和服务器之间运行iperf：

我可以轻松地在客户机和redis企业服务器之间传输超过700mbit/sec的数据，而服务器的处理速度是9.5mb/sec。所以，问题不在于网络带宽。
所以，我们的立场是：
同样的代码在azureredis上运行得很好，但是当我们切换到redis企业版时，却会导致数千次超时。
redis enterprise每秒处理4000个操作，每秒发送9兆，通常可以在几毫秒内处理一个操作，最长的是15毫秒。
我可以在客户端和服务器之间发送700+mb/秒。
然而，工作线程池随着对redis的挂起请求而建立，并最终超时。
我被困在这里了。下一步诊断这个问题的好方法是什么？谢谢！