繼上一集.NET Core 遷移躺坑記裡說到遇到的各種問題並且弄了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世界真是博大精深…
朋友會在“發現-看一看”看到你“在看”的內容