最近在進行開發過程當中,基於都是接口開發,A站接口訪問B接口接口來請求數據,而在這個過程當中咱們使用的是HttpClient這個框架,固然也是微軟本身的框架,性能當前沒有問題,但若是你直接使用官方的寫法,在高併發時候,會有很大的性能隱患,由於它官方使用的是using的方式,而對於請求量比較大時,這種方法對TCP創建也會太高,即便用完立刻釋放也會有不少time_out的請求,全部決定把某個用到httpclient的組件作成靜態化的!json
明細api
統計併發
調用,中規中矩的寫法app
using (var http = new HttpClient()) { var json = JsonConvert.SerializeObject(new { target_index = projectName, timestamp = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ"), Level = level.ToString(), Message = message }); json = json.Replace("target_index", "@target_index").Replace("timestamp", "@timestamp"); var httpContent = new StringContent(json, Encoding.UTF8); httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json"); var result = http.PostAsync(apiLoggerUri, httpContent).Result; }
優化它,作成TCP長連接,因此請求走一個通道框架
private static readonly HttpClient _httpClient; private ApiLoggerOptions _config; static ApiLogger() { _httpClient = new HttpClient(); _httpClient.Timeout = new TimeSpan(0, 0, 10); _httpClient.DefaultRequestHeaders.Connection.Add("keep-alive"); }
keep-alive關鍵字能夠理解爲一個長連接,超時時間也能夠在上面進行設置,例如10秒的超時時間,固然併發量太大,這個10秒應該會拋棄不少請求高併發
發送請求的代碼沒有了using,即這個httpclient不會被手動dispose,而是由系統控制它,固然你的程序重啓時,這也就被回收了。性能
var json = JsonConvert.SerializeObject(new { target_index = projectName, timestamp = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ"), Level = level.ToString(), Message = message }); json = json.Replace("target_index", "@target_index").Replace("timestamp", "@timestamp"); var httpContent = new StringContent(json, Encoding.UTF8); httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json"); _httpClient.PostAsync(apiLoggerUri, httpContent).Wait();
經過上面的改造,咱們我係統性能獲得了改善,TCP的鏈接數也降下來了優化
因此對於長連接的多路複用技術,相對於請求過多的狀況仍是最省資源的!spa