.NET Core 遷移躺坑記續集--Win下莫名其妙的超時

上一集裏說到遇到的各類問題而且弄了n個解決方案以後,特別是對於問題4的解決方案對於切換了HttpClientFactoryhtml

我用了你家netcore 2.1下專門解決以前HttpClient口病已久的靈丹妙藥了,信心滿滿的上線…..而後掛了,該超時的繼續超服務器

 

其中這個問題比較詭異在於超時的主要集中在兩臺機器上(俗稱兩兄弟了)微信

因爲不明真相究竟是什麼致使的,並且接下來又要到五一了,爲了歡度五一這麼一個偉大艱鉅的任務,爲了證實遷移core的偉大光榮正確,怎麼也要解決掉這個問題運維

 

步驟一,先確認問題的復現

首先直接放棄在任何測試環境復現的想法,由於以前在測試HttpClientFactory的時候已經在測試環境裏進行過多批次各類場景的壓測,不管是長時低壓,長時高壓,短時高壓都進行過都沒發生過測試

並且就算是線上也就2臺機器有問題google

因此讓運維提供ip,指向到這臺服務器後,使用superbenchmarker對其進行壓測spa

壓測中發現這個….很穩定3d

穩定5分鐘,掛個2分鐘htm

 

image

綠色線爲RPS每秒請求數,紫色是請求響應時間,發現綠色線穩定5分鐘後,會忽然沒有了(請求卡住了),等個2分鐘後忽然紫色線忽然冒個刺(等待已久的請求終於響應了)而後綠色線又起來了(請求恢復正常)blog

 

步驟二,確認超時的時候發生了什麼

次日,開好壓測,由於確認了每5分鐘後會超時2分鐘這個時間,等着個四分鐘左右跑到運維那坐着,看下超時期間到底發生了什麼。

而後我就絕望了。

常規的好比CPU/內存之類一切正常,考慮到HttpClient有過的歷史缺陷好比 .NET HttpClient 的缺陷和文檔錯誤讓開發人員倍感沮喪 也特地關注過端口號之類的,也一切正常。

 

步驟三,遷移前的Framework怎麼沒有問題,是Core的鍋嗎

爲了證實這個事情,準備了2個console

一個Framework下使用靜態的HttpClient每100ms調用某外部接口

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

這個結果讓我絕望的平方

結果顯示Framework下一切正常,只有Core有問題

企業微信截圖_15562571114243

後續在補充了幾個不一樣姿式的Core版本的console來測試

包括

  1.將SetHandlerLifetime設置爲InfiniteTimeSpan

  2.不用HttpClientFactory直接new一個靜態HttpClient(和Framework一摸同樣的姿式)

依然都會又超時的問題

 

因爲網上google翻了個遍沒找到相似的說法

此時的心裏想法:難道我要開歷史的倒車了麼(難道只有我有問題麼?仍是說我哪裏姿式有問題?別人怎麼都好好的?難作別人都是假的?網上吹的那麼厲害全都是瞎BB?….各類草泥馬奔騰而過)

 

柳暗花明,絕望的時候找下組織吧

而後就在某微信羣裏發出求救信號

image

最後獲得一個看起來有點靠譜的方案

image

(截圖裏的內容,)

image

 

文字版描述:建立HttpClient的時候設置UseProxy爲false,此值默認值是true

 

而後使用這個改造後在打包一個console進行測試,此次結果終於看到了但願的曙光了

image

 

因爲根據以前的規律每5分鐘以後會掛2分鐘,能活個10分鐘基本證實修改有效

 

跟着這個將站點都修改了UseProxy=false打包上去,進行壓測

image

 

跑了好幾個小時,目前爲止並無發生再超時的問題了,如今基本實錘問題解決了

 

最後總結

不管你是new一個靜態HttpClient仍是經過HttpClientFactory去建立HttpClient,記得要將UseProxy=false(固然,除非你要用proxy那就沒轍)

 

固然,最後有幾個疑點我也不是太清楚

好比

爲何線上就2臺機器恆定有問題?

而其餘機器則比較穩定(實際線上服務器接近30臺)?

爲何是穩5分鐘後超時2分鐘(這個5和這個2是哪裏設置的)?

UseProxy在這裏又是起到了什麼樣的做用?

 

羣裏小夥伴給了這麼一個解釋

image

 

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

.Net世界真是博大精深…

 

image

相關文章
相關標籤/搜索