.NET Core 迁移躺坑记续集之Win下莫名其妙的超时

介绍.NET Core迁移之谜：Win环境下的超时困扰续写

在.NET Core迁移之旅中，我遭遇了一场神秘的超时风波。这次，我将与大家分享这段“躺坑记”的续集，带大家揭开Win环境下超时的神秘面纱。请跟随我的脚步，一同这场技术迷宫的奥秘。

经过一番激烈的技术较量后，针对之前遇到的HttpClient问题，我采用了针对core 2.1版本的灵丹妙药——HttpClientFactory。满怀信心地部署后，问题依旧，超时现象如鬼魅般挥之不去。

这次的问题更为诡异，主要集中在两台服务器上，仿佛是一对“兄弟”。由于难以捉摸其背后的真正原因，加上即将到来的五一假期，我决定不能就此放弃。为了证明这次迁移的正确性，我必须解决这个难题。

一、复现问题

我放弃了在测试环境中复现问题的想法。因为在测试环境中使用HttpClientFactory时，已经进行了多种场景的压测，均未发现问题。于是，我决定直接指向线上服务器进行深入研究。

使用superbenchmarker进行压测后，我发现了一个规律：服务器稳定运行5分钟后，会突然停止响应2分钟，然后恢复正常。绿色线（RPS每秒请求数）的稳定状态与紫色线（请求响应时间）的波动形成了鲜明对比。

二、超时真相

在压测过程中，我密切监视着服务器的状态。令我绝望的是，CPU、内存等常规指标一切正常。考虑到HttpClient的历史问题，我也检查了端口号，同样一切正常。

三、是Core的锅吗？

为了验证这个问题，我准备了两个console程序，分别使用Framework和Core调用外部接口。结果显示，Framework一切正常，而Core则存在问题。这个结果让我绝望之余，更加坚定了解决问题的决心。

随后，我尝试了几种不同版本的Core console进行测试，包括将SetHandlerLifetime设置为InfiniteTimeSpan以及不使用HttpClientFactory直接创建静态HttpClient。问题依然存在。

经过大量的测试和研究，我在互联网上寻找类似案例，却一无所获。此刻的我陷入沉思：难道我要回到过去，采用旧的技术框架吗？或者是我在使用Core的过程中存在某些误区？为何其他人使用得如此顺利？网上的赞誉之声是否都是真实的？

这次的之旅充满了挑战和困惑。但作为一个技术者，我深知问题的背后往往隐藏着宝贵的经验和教训。我将继续深入，寻找解决这个问题的答案。希望这次分享能够引起更多技术爱好者的关注，共同揭开这个神秘的超时之谜。在长沙的网络推广领域，最近有一篇关于.NET Core迁移的系列文章引起了广泛关注。这篇文章是续集，讲述了一次在Windows环境下遭遇的神秘超时问题。让我们一起跟随作者的笔触，深入了解这次问题的来龙去脉。

正当开发者们陷入绝望之际，一个转机出现了。在微信群里发出求救信号后，终于得到了一个看似靠谱的解决方案。方案的核心在于设置HttpClient的UseProxy属性为false。这个属性值默认是true，但在某些特定情况下，将其设置为false可能会带来意想不到的效果。

通过文字版描述，开发者们在创建HttpClient时进行了这样的设置，并在打包后进行了一次console测试。这次测试的结果终于看到了希望的曙光。由于之前的经验告诉他们，每隔5分钟系统会挂掉2分钟，因此只要能在10分钟内稳定运行，基本上就可以证明修改是有效的。

随后，开发者们将这个设置应用到所有站点，进行了压测。经过几个小时的连续运行，再也没有出现超时的问题。这基本上已经确定了问题的解决方向。

仍然有几个疑点让作者感到困惑。为什么线上只有两台机器会恒定出现问题，而其他接近30台机器则表现稳定？那个每隔5分钟超时2分钟的规律究竟是如何设置的？在这里，UseProxy到底起到了什么样的作用？

对于这些问题，群里的小伙伴给出了一个解释，但作者依然感到不太理解。他感叹说“.Net世界真是博大精深”。

这篇文章为大家讲述了这次.NET Core迁移过程中的一次挑战，希望能够对大家有所帮助。如果有任何疑问，欢迎留言咨询。长沙网络推广会及时回复大家的。也要感谢大家对狼蚁SEO网站的支持。如果读者觉得本文有帮助，欢迎转载，但请务必注明出处。

对于上述的疑问，建议开发者们深入研究HttpClient的UseProxy属性的作用机制，以及它在不同环境下的表现。也可以考虑从网络配置、服务器设置等方面入手，寻找可能导致问题的其他原因。在这个过程中，或许会有更多的发现和学习。

这篇文章不仅为大家提供了一个解决.NET Core迁移中遇到超时问题的实例，也展示了长沙网络推广的实力和态度。希望大家能够从中受益，共同推动网络技术的发展。 （结束）