讲了上一集遇到的各种问题，得到N个解决方案，特别是问题4的解决方案，HttpClientFactory就切换了

我用你们的netcore 2.1万能药解决了长期存在的HttpClient问题，信心满满的上线了.然后挂断，超时时间继续超过

这个问题挺奇怪的，因为超时主要集中在两台机器上(俗称两兄弟)

因为不知道是什么造成的真相，又将是五一节，为了庆祝像五一节这样伟大而艰巨的任务，为了证明迁移核心的伟大荣耀是正确的，如何解决这个问题？

第一步，首先确认问题的重现

首先，直接放弃在任何测试环境下进行复现的想法，因为在测试HttpClientFactory之前，已经在测试环境下进行了多批次各种场景下的压力测试，无论是长期低压、长期高压还是短期高压。从未发生过

而且即使是在线，也只有两台机器出现问题

因此，让操作和维护提供ip，指向该服务器，并使用superbenchmarker对其进行测试

我在压力测试中发现了这个.非常稳定

稳定5分钟，悬挂2分钟

绿线是每秒的RPS请求，紫色是请求响应时间。当发现绿线稳定5分钟后会突然消失(请求被卡住)。等待2分钟后，紫色线突然尖刺(期待已久的请求终于响应)，然后绿色线再次上升(请求恢复正常)

第二步，确认超时发生时发生了什么

第二天开始试压，因为确认每5分钟会有2分钟的超时。等了大概4分钟，跑到运维办看看超时期间发生了什么。

然后我绝望了。

考虑到HttpClient的历史缺陷，像CPU/内存这样的常规东西是正常的。我也特别注意了端口号之类的，一切正常。

步骤3:为什么迁移前框架没有问题？是核心的锅吗

为了证明这一点，准备了两个控制台

在框架下，静态HttpClient用于每100毫秒调用一次外部接口

在内核下使用HttpClientFactory也需要每100毫秒调用一次外部接口

这个结果让我绝望了

结果显示框架下一切正常，只有Core有问题

通过增加几个不同姿势的Core版本控制台进行了后续测试

包括

1.将SetHandlerLifetime设置为InfiniteTimeSpan

2.直接创建一个没有HttpClientFactory的静态HttpClient(与框架完全相同的姿态)

还是会再次超时

因为谷歌已经在互联网上搜索过了，我找不到类似的说法

这时，我内心的想法是：我一定要在历史上倒退吗(只有我有问题吗？还是我的姿势有问题？为什么其他人都很好？别人都是假的吗？都是盲BB在网上吹得这么厉害。各种草泥马疾驰而过)

当你绝望的时候，找到组织

然后在微信群里发求救信号

最后，我得到了一个看起来有点可靠的计划

(截图中的内容，)

文本描述：创建HttpClient时，将UseProxy设置为false，该值的默认值为true

然后用这个转换打包一个控制台进行测试，这个结果终于看到了希望的曙光

因为按照之前的规则，每5分钟就会挂2分钟，住10分钟基本证明修改是有效的

在此之后，所有的站点都被修改，UseProxy=false被打包并测试

跑了几个小时，到目前为止还没有超时问题，现在基本实锤问题已经解决了

最后总结

无论您是新的静态HttpClient还是通过HttpClientFactory创建一个HttpClient，请记住UseProxy=false(当然，除非您想使用代理，否则您无能为力)

当然最后也有几个疑惑，我也不太清楚。

诸如

为什么两台机器持续在线会出现问题？

其他机器相对稳定(其实有近30台在线服务器)？

为什么稳定了5分钟然后又加班了2分钟(这5和这2套呢)？

UseProxy在这里扮演什么角色？

小组中的小伙伴给出了这样的解释

但是，我还是不太懂T-T。

那个。网络世界真的很深刻…

摘要

以上就是《赢了》续集下莫名的超时。网芯迁移躺在坑里，这是边肖介绍的。希望对大家有帮助。如果你有任何问题，请给我留言，边肖会及时回复你。非常感谢您对我们网站的支持！如果你觉得这篇文章对你有帮助，请转载，请注明出处，谢谢！