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

上一集里说到遇到的各种问题并且弄了n个解决方案之后,特别是对于问题4的解决方案对于切换了HttpClientFactory

我用了你家netcore 2.1下专门解决之前HttpClient口病已久的灵丹妙药了,信心满满的上线…..然后挂了,该超时的继续超

其中这个问题比较诡异在于超时的主要集中在两台机器上(俗称两兄弟了)

由于不明真相到底是什么导致的,而且接下来又要到五一了,为了欢度五一这么一个伟大艰巨的任务,为了证明迁移core的伟大光荣正确,怎么也要解决掉这个问题

步骤一,先确认问题的复现

首先直接放弃在任何测试环境复现的想法,因为之前在测试HttpClientFactory的时候已经在测试环境里进行过多批次各种场景的压测,无论是长时低压,长时高压,短时高压都进行过都没发生过

而且就算是线上也就2台机器有问题

所以让运维提供ip,指向到这台服务器后,使用superbenchmarker对其进行压测

压测中发现这个….很稳定

稳定5分钟,挂个2分钟

绿色线为RPS每秒请求数,紫色是请求响应时间,发现绿色线稳定5分钟后,会突然没有了(请求卡住了),等个2分钟后突然紫色线突然冒个刺(等待已久的请求终于响应了)然后绿色线又起来了(请求恢复正常)

步骤二,确认超时的时候发生了什么

第二天,开好压测,因为确认了每5分钟后会超时2分钟这个时间,等着个四分钟左右跑到运维那坐着,看下超时期间到底发生了什么。

然后我就绝望了。

常规的比如CPU/内存之类一切正常,考虑到HttpClient有过的历史缺陷比如 .NET HttpClient 的缺陷和文档错误让开发人员倍感沮丧 也特意关注过端口号之类的,也一切正常。

步骤三,迁移前的Framework怎么没有问题,是Core的锅吗

为了证明这个事情,准备了2个console

一个Framework下使用静态的HttpClient每100ms调用某外部接口

一个Core下使用HttpClientFactory也是每100ms调用某外部接口

这个结果让我绝望的平方

结果显示Framework下一切正常,只有Core有问题

后续在补充了几个不同姿势的Core版本的console来测试

包括

1.将SetHandlerLifetime设置为InfiniteTimeSpan

  2.不用HttpClientFactory直接new一个静态HttpClient(和Framework一摸一样的姿势)

依然都会又超时的问题

由于网上google翻了个遍没找到类似的说法

此时的内心想法:难道我要开历史的倒车了么(难道只有我有问题么?还是说我哪里姿势有问题?别人怎么都好好的?难道别人都是假的?网上吹的那么厉害全都是瞎BB?….各种草泥马奔腾而过)

柳暗花明,绝望的时候找下组织吧

然后就在某微信群里发出求救信号

最后得到一个看起来有点靠谱的方案

(截图里的内容, 文字版描述:创建HttpClient的时候设置UseProxy为false,此值默认值是true)

然后使用这个改造后在打包一个console进行测试,这次结果终于看到了希望的曙光了

由于根据之前的规律每5分钟之后会挂2分钟,能活个10分钟基本证明修改有效

跟着这个将站点都修改了UseProxy=false打包上去,进行压测

跑了好几个小时,目前为止并没有发生再超时的问题了,现在基本实锤问题解决了

最后总结

无论你是new一个静态HttpClient还是通过HttpClientFactory去创建HttpClient,记得要将UseProxy=false(当然,除非你要用proxy那就没辙)

当然,最后有几个疑点我也不是太清楚

比如

为什么线上就2台机器恒定有问题?

而其他机器则比较稳定(实际线上服务器接近30台)?

为什么是稳5分钟后超时2分钟(这个5和这个2是哪里设置的)?

UseProxy在这里又是起到了什么样的作用?

群里小伙伴给了这么一个解释

然而我依然不是太理解T-T

.Net世界真是博大精深…

原文地址:https://www.cnblogs.com/leolaw/p/10776451.html

时间: 2024-10-29 15:36:45

.NET Core 迁移躺坑记续集--Win下莫名其妙的超时的相关文章

.NET Core爬坑记 1.0 项目文件

前言: 之所以要写这个系列是因为在移植项目到ASP.NET Core平台的过程中,遇到了一些“新变化”,这些变化有编译方面的.有API方面的,今天要讲的是编译方面的一些问题.我把它们整理后分享出来,以便各位博友不要再遇到这些坑. 在Dotnet Core RC2版本中,project.json 管理着整个项目,包括编译文件.依赖包管理.版本信息.平台依赖与发布等功能. 关于项目中引用: 比如我们一般看到Project.json中一般会有如下内容: "dependencies": { &

UiAutomator2.0升级填坑记

UiAutomator2.0升级填坑记 SkySeraph May. 28th 2017 Email:[email protected] 更多精彩请直接访问SkySeraph个人站点:www.skyseraph.com 啰嗦 Google Android Developers 在2015年3月就发布了UiAutomator 2.0版本(下文简称U2),而公司的核心产品中用到还是UiAutomator老版本(下文简称U1),业界用U2的也不是很多,虽然有诸多问题和不便(如高版本OS中不支持Remo

windows container 踩坑记

windows container 踩坑记 Intro 我们有一些服务是 dotnet framework 的,不能直接跑在 docker linux container 下面,最近一直在折腾把它部署在 windows container 下,折腾的有点恶心,记录一下. Windows Container 介绍 Windows Container 是微软在 Windows 上的虚拟化实践,它可以提供操作系统级别的虚拟化. 通过我们说的容器化大多是指 Linux Container,基于 linu

ASP.NET MVC升级到ASP.NET Core MVC踩坑小结

原文:ASP.NET MVC升级到ASP.NET Core MVC踩坑小结 写在前面 ASP.NET Core是微软新推出的支持跨平台.高性能.开源的开发框架,它的优势不必多说,因为已经说得太多了.当然,现在依然有着数量庞大的系统运行于.NET Framework上,由于有大量的Break Changes,很多项目项目团队也不敢贸然升级,其中的考量也不全部是技术原因,更多的可能还是业务推进因素. 小编自年前开始考虑升级一套电商系统,原先是基于.NET Framework 4.5的,打算直接升级到

Net Core迁移到MSBuild

Net Core迁移到MSBuild平台(二) 阅读目录 一.前言 二.XML定义 三.结语 回到目录 一.前言 在上一篇文章.Net Core迁移到MSBuild的多平台编译问题中,简单的讲了下新的项目配置文件中的节点配置,这篇我将用一些例子来详细讲下从project.json迁移到msbuild过程的节点配置.做过完整迁移新项目配置文件的朋友,肯定会觉得新的项目配置文件Msbuild的配置太扯了,虽然能直接编辑项目文件,但整个配置文件中没有了像project.json中的智能提示,当你在打开

踩坑记:httpComponents 的 EntityUtils

今天写的一个服务程序,有人报告获得的数据中文乱码,而我是用 apache 通过 httpComponents 去取得数据的,于是开启日志的 debug 级别. 在日志里果然发现中文不见了,有乱码出现: 2014-07-02 16:35:01.348 DEBUG [Wire.java:86] http-outgoing-8 << "<?xml version="1.0" encoding="UTF-8"?>... subject=&q

cocos2dx lua invalid &#39;cobj&#39; in function &#39;lua_cocos2dx‘ 躺坑

for 循环中保存了创建的 Node节点到 userdata 数据结构中 再次引用发现 一直报 LUA ERROR: [string ".\framework/cocos2dx/NodeEx.lua"]:112: invalid ' 'cobj' in function 'lua_cocos2dx_Node_removeFromParentAndCleanup' dump 后发现一直有值,不名所以,追踪quick源码发现根本没有cobj引用 查阅质料发现 lua 保存的这个node值相

Spark踩坑记——数据库(Hbase+Mysql)转

转自:http://www.cnblogs.com/xlturing/p/spark.html 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己踩到的一些坑进行记录. Spark Streaming持久化设计

Spring @Transactional踩坑记

@Transactional踩坑记 总述 ? Spring在1.2引入@Transactional注解, 该注解的引入使得我们可以简单地通过在方法或者类上添加@Transactional注解,实现事务控制. 然而看起来越是简单的东西,背后的实现可能存在很多默认规则和限制.而对于使用者如果只知道使用该注解,而不去考虑背后的限制,就可能事与愿违,到时候线上出了问题可能根本都找不出啥原因. 踩坑记 1. 多数据源 事务不生效 背景介绍 ? 由于数据量比较大,项目的初始设计是分库分表的.于是在配置文件中