.NET 5应用部署于Docker Linux容器后Redis连接性能异常如何解决？

一、容器网络层面问题 #

网络是跨环境部署最常见的性能差异来源，IIS直接运行在Windows宿主机网络栈，而Docker Linux容器默认网络模式会产生额外转发开销：

• 先测试容器到Redis的基础网络延迟：进入容器内部执行ping <Redis服务地址>、redis-cli --latency -h <Redis服务地址> -p <端口>，确认基础网络延迟是否本身就高于1ms，如果是优先解决底层网络问题
• 调整Docker网络模式：如果当前使用默认bridge网络，切换为host网络模式测试，host模式下容器直接复用宿主机网络栈，可消除NAT转发、端口映射的额外开销
• 排查MTU适配问题：Docker默认bridge网络MTU通常为1500，如果上层网络（如VPC、物理交换机）的MTU更小，会出现频繁分片丢包、重传的情况，将Docker网络MTU调整为与底层网络一致即可解决

二、StackExchange.Redis客户端Linux环境适配问题 #

该客户端在Windows和Linux环境下的默认配置、运行表现存在差异，容易出现适配问题：

• 调整.NET线程池配置：.NET Core在Linux容器中默认最小线程数设置偏低，高并发场景下请求排队会导致Redis调用表观延迟升高，可在程序启动入口添加配置：

// 数值可根据实际峰值并发量调整，通常设置为高于峰值并发数即可
ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100);

• 优化客户端连接配置：确认未开启不必要的SSL配置（Redis服务未开启SSL时需要显式关闭ssl参数），Linux下TLS握手开销远高于Windows；同时可适当调低超时阈值，避免异常请求阻塞连接
• 排查同步阻塞调用：如果代码中大量使用*Async().Result、Wait()这类同步阻塞写法，在Linux线程池调度策略下更容易触发线程饥饿，表现为调用延迟远高于Windows环境，统一替换为await异步调用即可

三、容器资源限制问题 #

Docker默认资源配额或GC配置不合理也会导致整体性能下降：

• 检查容器资源占用：执行docker stats <容器ID>查看高并发场景下的CPU、内存使用率，确认是否出现CPU打满、内存触顶触发频繁GC的情况
• 调整GC模式：.NET Core在Linux容器中默认使用工作站GC，高并发场景下改为服务器GC可大幅提升性能，在项目.csproj文件中添加配置：

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>

• 放宽CPU限流配置：如果部署时设置了--cpus之类的CPU配额限制，高并发下CPU时间片不足会导致所有操作同步变慢，可适当调高CPU配额测试

四、其他路径开销问题 #

• 验证域名解析开销：容器内部的DNS解析策略可能和Windows宿主机不同，可直接在Redis连接字符串中使用IP地址代替域名测试，确认是否存在DNS解析耗时过高的问题
• 排查路径限流策略：确认容器出口IP是否在Redis服务的白名单内，是否存在针对容器IP的限流规则，或者网络路径上多了代理、WAF之类的中间层带来额外转发开销

内容的提问来源于stack exchange，提问作者Simon Simu