StackExchange.Redis 使用名为 synctimeout 的配置设置进行同步操作，该设置的默认值为 1000 毫秒。 如果同步调用未在规定时间内完成，StackExchange.Redis 客户端会引发类似于以下示例的超时错误。
System.TimeoutException: Timeout performing MGET 2728cc84-58ae-406b-8ec8-3f962419f641, inst: 1,mgr: Inactive, queue: 73, qu=6, qs=67, qc=0, wr=1/1, in=0/0 IOCP: (Busy=6, Free=999, Min=2,Max=1000), WORKER (Busy=7,Free=8184,Min=2,Max=8191)
此错误消息中包含的指标可以指出问题的原因和可能的解决方法。 下表包含有关错误消息指标的详细信息。
| 错误消息指标 | 详细信息 |
|---|---|
| inst | 在上一个时间片中：发出了 0 个命令 |
| mgr | 套接字管理器正在执行 socket.select，也就是说，它在请求 OS 指示一个需要执行某些操作的套接字；大致说来：读取器并没有主动从网络读取内容，因为它认为不需执行任何操作 |
| 队列 | 总共有 73 个正在进行的操作 |
| qu | 正在进行的操作中，有 6 个操作位于未发送队列中，尚未写入到出站网络 |
| qs | 正在进行的操作中，有 67 个操作已发送给服务器，但尚未得到响应。 响应可能为 Not yet sent by the server 或 sent by the server but not yet processed by the client. |
| qc | 正在进行的操作中，有 0 个操作已经有回复，但尚未标记为完成，因为正在完成循环中进行等待 |
| wr | 存在活动的写入器（这意味着系统不会忽略这 6 个尚未发送的请求）字节/活动写入器 |
| 位于 | 没有活动的读取器，NIC 字节/活动读取器上没有可供读取的字节 |
有关线程池增长的重要详细信息
CLR 线程池具有两种类型的线程 —“辅助角色”和“I/O 完成端口”（又称为 IOCP）线程。
- 对于诸如处理
Task.Run(…)或ThreadPool.QueueUserWorkItem(…)方法这类事务，使用辅助角色线程。 需要在后台线程上进行工作时，CLR 中的各种组件也会使用这些线程。 - 进行异步 IO（例如从网络进行读取）时，使用 IOCP 线程。
线程池按需提供新的辅助角色线程或 I/O 完成线程（没有任何限制），直到它达到每种线程类型的“最小值”设置。 默认情况下，最小线程数设置为系统上的处理器数。
一旦现有（忙碌）线程数达到“最小”线程数，线程池便会将插入新线程的速率限制为每 500 毫秒一个线程。 通常，如果系统中出现需要 IOCP 线程的突发工作，则它会非常快速地处理该工作。 但是，如果突发工作多于配置的“最小值”设置，则在处理某些工作时会出现一定的延迟，因为线程池会等待发生以下两种情况之一。
- 一个现有线程释放，以便处理工作。
- 在 500 毫秒内没有任何现有线程释放，因此会创建一个新线程。
基本上，这意味着忙碌线程数大于最小线程数，在应用程序处理网络流量之前可能需要付出 500 毫秒延迟。 此外请务必注意，当现有线程保持空闲状态的时间超过 15 秒（基于我记得的内容）时，会清理它，并且这种增长和收缩的循环可能会重复。
如果我们考虑一个来自 StackExchange.Redis（内部版本 1.0.450 或更高版本）的示例错误消息，会看到它现在会打印线程池统计信息（请参阅下面的 IOCP 和辅助角色详细信息）。
System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)
在前面的示例中，可以看到对于 IOCP 线程有 6 个忙碌线程，而系统配置为允许最少 4 个线程。 在这种情况下，客户端可能会遇到两个 500 毫秒延迟，因为 6 > 4。
请注意，如果 IOCP 或辅助角色线程受到限制，则 StackExchange.Redis 可以会超时。
建议
考虑到此信息，我们强烈建议客户将 IOCP 和辅助角色线程的最小配置值设置为大于默认值。 我们无法提供有关此值应是多少的通用指导，因为一个应用程序的合适值对于另一个应用程序会太高/低。 此设置还可能会影响复杂应用程序其他部分的性能，因此每个客户需要按照其特定需求来微调此设置。 开始时设置为 200 或 300 会比较好，随后可进行测试并根据需要进行调整。
如何配置此设置：
-
在 ASP.NET 中，可在 web.config 中的
备注
此配置元素中指定的值是按核心设置。 例如，如果使用 4 核计算机，并且希望 minIOThreads 设置在运行时为 200，则使用
-
在 ASP.NET 外部，可使用 ThreadPool.SetMinThreads(…) API。
启用服务器 GC，以便在使用 StackExchange.Redis 时在客户端上获取更多吞吐量
启用服务器 GC 可以在使用 StackExchange.Redis 时优化客户端并提供更好的性能和吞吐量。 有关服务器 GC 以及如何启用它的详细信息，请参阅以下文章：
- 若要启用服务器 GC
- 垃圾回收基础
- 垃圾回收和性能
Azure Redis 缓存的 ASP.NET 会话状态提供程序
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-aspnet-session-state-provider
Redis 缓存的 ASP.NET 输出缓存提供程序
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-aspnet-output-cache-providerAzure
将 Spring Boot Initializer 应用配置为使用云中的 Redis 和 Azure Redis 缓存
https://docs.microsoft.com/zh-cn/java/azure/spring-framework/configure-spring-boot-initializer-java-app-with-redis-cache
Redis 缓存常见问题
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-faq
如何排查 Azure Redis 缓存问题
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-how-to-troubleshoot#client-side-troubleshooting
StackExchange.Redis 最佳做法
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-faq#stackexchangeredis-best-practices
有关线程池增长的重要详细信息(CLR 线程池具有两种类型的线程 —“辅助角色”和“I/O 完成端口”（又称为 IOCP）线程)
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-faq#stackexchangeredis-best-practices
StackExchange.Redis 超时异常
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-how-to-troubleshoot#stackexchangeredis-timeout-exceptions
如何为高级 Azure Redis 缓存配置 Redis 群集功能
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-how-to-premium-clustering
https://gist.github.com/JonCole/e65411214030f0d823cb
https://docs.microsoft.com/zh-cn/dotnet/standard/garbage-collection/fundamentals
https://docs.microsoft.com/zh-cn/azure/redis-cache/cache-faq#important-details-about-threadpool-growth
https://blog.marsen.me/2016/11/21/aspdotnet_threadpool_and_redis/