<acronym id="s8ci2"><small id="s8ci2"></small></acronym>
<rt id="s8ci2"></rt><rt id="s8ci2"><optgroup id="s8ci2"></optgroup></rt>
<acronym id="s8ci2"></acronym>
<acronym id="s8ci2"><center id="s8ci2"></center></acronym>
0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

HttpClient優化思路

馬哥Linux運維 ? 來源:CSDN-仰望星空的塵埃 ? 2023-09-12 11:18 ? 次閱讀

HttpClient優化思路:

池化

長連接

httpclient和httpget復用

合理的配置參數(最大并發請求數,各種超時時間,重試次數)

異步

多讀源碼

1.背景

我們有個業務,會調用其他部門提供的一個基于http的服務,日調用量在千萬級別。使用了httpclient來完成業務。之前因為qps上不去,就看了一下業務代碼,并做了一些優化,記錄在這里。

先對比前后:優化之前,平均執行時間是250ms;

優化之后,平均執行時間是80ms,降低了三分之二的消耗,容器不再動不動就報警線程耗盡了,清爽~

2.分析

項目的原實現比較粗略,就是每次請求時初始化一個httpclient,生成一個httpPost對象,執行,然后從返回結果取出entity,保存成一個字符串,最后顯式關閉response和client。

我們一點點分析和優化:

2.1 httpclient反復創建開銷

httpclient是一個線程安全的類,沒有必要由每個線程在每次使用時創建,全局保留一個即可。

2.2 反復創建tcp連接的開銷

tcp的三次握手與四次揮手兩大裹腳布過程,對于高頻次的請求來說,消耗實在太大。試想如果每次請求我們需要花費5ms用于協商過程,那么對于qps為100的單系統,1秒鐘我們就要花500ms用于握手和揮手。又不是高級領導,我們程序員就不要搞這么大做派了,改成keep alive方式以實現連接復用!

2.3 重復緩存entity的開銷

原本的邏輯里,使用了如下代碼:

HttpEntityentity=httpResponse.getEntity();

Stringresponse=EntityUtils.toString(entity);

這里我們相當于額外復制了一份content到一個字符串里,而原本的httpResponse仍然保留了一份content,需要被consume掉,在高并發且content非常大的情況下,會消耗大量內存。并且,我們需要顯式的關閉連接,ugly。

3.實現

按上面的分析,我們主要要做三件事:一是單例的client,二是緩存的?;钸B接,三是更好的處理返回結果。一就不說了,來說說二。

提到連接緩存,很容易聯想到數據庫連接池。httpclient4提供了一個PoolingHttpClientConnectionManager 作為連接池。接下來我們通過以下步驟來優化:

3.1 定義一個keep alive strategy

關于keep-alive,本文不展開說明,只提一點,是否使用keep-alive要根據業務情況來定,它并不是靈丹妙藥。還有一點,keep-alive和time_wait/close_wait之間也有不少故事。

在本業務場景里,我們相當于有少數固定客戶端,長時間極高頻次的訪問服務器,啟用keep-alive非常合適

再多提一嘴,http的keep-alive 和tcp的KEEPALIVE不是一個東西?;氐秸?,定義一個strategy如下:

ConnectionKeepAliveStrategymyStrategy=newConnectionKeepAliveStrategy(){
@Override
publiclonggetKeepAliveDuration(HttpResponseresponse,HttpContextcontext){
HeaderElementIteratorit=newBasicHeaderElementIterator
(response.headerIterator(HTTP.CONN_KEEP_ALIVE));
while(it.hasNext()){
HeaderElementhe=it.nextElement();
Stringparam=he.getName();
Stringvalue=he.getValue();
if(value!=null&¶m.equalsIgnoreCase
("timeout")){
returnLong.parseLong(value)*1000;
}
}
return60*1000;//如果沒有約定,則默認定義時長為60s
}
};

3.2 配置一個PoolingHttpClientConnectionManager

PoolingHttpClientConnectionManagerconnectionManager=newPoolingHttpClientConnectionManager();
connectionManager.setMaxTotal(500);
connectionManager.setDefaultMaxPerRoute(50);//例如默認每路由最高50并發,具體依據業務來定

也可以針對每個路由設置并發數。

3.3 生成httpclient

httpClient=HttpClients.custom()
.setConnectionManager(connectionManager)
.setKeepAliveStrategy(kaStrategy)
.setDefaultRequestConfig(RequestConfig.custom().setStaleConnectionCheckEnabled(true).build())
.build();

?

注意:使用setStaleConnectionCheckEnabled方法來逐出已被關閉的鏈接不被推薦。更好的方式是手動啟用一個線程,定時運行closeExpiredConnections 和closeIdleConnections方法,如下所示。

?

publicstaticclassIdleConnectionMonitorThreadextendsThread{

privatefinalHttpClientConnectionManagerconnMgr;
privatevolatilebooleanshutdown;

publicIdleConnectionMonitorThread(HttpClientConnectionManagerconnMgr){
super();
this.connMgr=connMgr;
}

@Override
publicvoidrun(){
try{
while(!shutdown){
synchronized(this){
wait(5000);
//Closeexpiredconnections
connMgr.closeExpiredConnections();
//Optionally,closeconnections
//thathavebeenidlelongerthan30sec
connMgr.closeIdleConnections(30,TimeUnit.SECONDS);
}
}
}catch(InterruptedExceptionex){
//terminate
}
}

publicvoidshutdown(){
shutdown=true;
synchronized(this){
notifyAll();
}
}

}

3.4 使用httpclient執行method時降低開銷

這里要注意的是,不要關閉connection。

一種可行的獲取內容的方式類似于,把entity里的東西復制一份:

res=EntityUtils.toString(response.getEntity(),"UTF-8");
EntityUtils.consume(response1.getEntity());

但是,更推薦的方式是定義一個ResponseHandler,方便你我他,不再自己catch異常和關閉流。在此我們可以看一下相關的源碼:

publicTexecute(finalHttpHosttarget,finalHttpRequestrequest,
finalResponseHandlerresponseHandler,finalHttpContextcontext)
throwsIOException,ClientProtocolException{
Args.notNull(responseHandler,"Responsehandler");

finalHttpResponseresponse=execute(target,request,context);

finalTresult;
try{
result=responseHandler.handleResponse(response);
}catch(finalExceptiont){
finalHttpEntityentity=response.getEntity();
try{
EntityUtils.consume(entity);
}catch(finalExceptiont2){
//Logthisexception.Theoriginalexceptionismore
//importantandwillbethrowntothecaller.
this.log.warn("Errorconsumingcontentafteranexception.",t2);
}
if(tinstanceofRuntimeException){
throw(RuntimeException)t;
}
if(tinstanceofIOException){
throw(IOException)t;
}
thrownewUndeclaredThrowableException(t);
}

//Handlingtheresponsewassuccessful.Ensurethatthecontenthas
//beenfullyconsumed.
finalHttpEntityentity=response.getEntity();
EntityUtils.consume(entity);//看這里看這里
returnresult;
}

可以看到,如果我們使用resultHandler執行execute方法,會最終自動調用consume方法,而這個consume方法如下所示:

publicstaticvoidconsume(finalHttpEntityentity)throwsIOException{
if(entity==null){
return;
}
if(entity.isStreaming()){
finalInputStreaminstream=entity.getContent();
if(instream!=null){
instream.close();
}
}
}

可以看到最終它關閉了輸入流。

4.其他

通過以上步驟,基本就完成了一個支持高并發的httpclient的寫法,下面是一些額外的配置和提醒:

4.1 httpclient的一些超時配置

CONNECTION_TIMEOUT是連接超時時間,SO_TIMEOUT是socket超時時間,這兩者是不同的。連接超時時間是發起請求前的等待時間;socket超時時間是等待數據的超時時間。

HttpParamsparams=newBasicHttpParams();
//設置連接超時時間
IntegerCONNECTION_TIMEOUT=2*1000;//設置請求超時2秒鐘根據業務調整
IntegerSO_TIMEOUT=2*1000;//設置等待數據超時時間2秒鐘根據業務調整

//定義了當從ClientConnectionManager中檢索ManagedClientConnection實例時使用的毫秒級的超時時間
//這個參數期望得到一個java.lang.Long類型的值。如果這個參數沒有被設置,默認等于CONNECTION_TIMEOUT,因此一定要設置。
LongCONN_MANAGER_TIMEOUT=500L;//在httpclient4.2.3中我記得它被改成了一個對象導致直接用long會報錯,后來又改回來了

params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT,CONNECTION_TIMEOUT);
params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT,SO_TIMEOUT);
params.setLongParameter(ClientPNames.CONN_MANAGER_TIMEOUT,CONN_MANAGER_TIMEOUT);
//在提交請求之前測試連接是否可用
params.setBooleanParameter(CoreConnectionPNames.STALE_CONNECTION_CHECK,true);

//另外設置http client的重試次數,默認是3次;當前是禁用掉(如果項目量不到,這個默認即可)
httpClient.setHttpRequestRetryHandler(newDefaultHttpRequestRetryHandler(0,false));

4.2 如果配置了nginx的話,nginx也要設置面向兩端的keep-alive

現在的業務里,沒有nginx的情況反而比較稀少。nginx默認和client端打開長連接而和server端使用短鏈接。

注意client端的keepalive_timeout和keepalive_requests參數,以及upstream端的keepalive參數設置,這三個參數的意義在此也不再贅述。

以上就是我的全部設置。通過這些設置,成功地將原本每次請求250ms的耗時降低到了80左右,效果顯著。

JAR包如下:

 

org.apache.httpcomponents
httpclient
4.5.6

代碼如下:

//Basic認證
privatestaticfinalCredentialsProvidercredsProvider=newBasicCredentialsProvider();
//httpClient
privatestaticfinalCloseableHttpClienthttpclient;
//httpGet方法
privatestaticfinalHttpGethttpget;
//
privatestaticfinalRequestConfigreqestConfig;
//響應處理器
privatestaticfinalResponseHandlerresponseHandler;
//jackson解析工具
privatestaticfinalObjectMappermapper=newObjectMapper();
static{
System.setProperty("http.maxConnections","50");
System.setProperty("http.keepAlive","true");
//設置basic校驗
credsProvider.setCredentials(
newAuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT,AuthScope.ANY_REALM),
newUsernamePasswordCredentials("",""));
//創建http客戶端
httpclient=HttpClients.custom()
.useSystemProperties()
.setRetryHandler(newDefaultHttpRequestRetryHandler(3,true))
.setDefaultCredentialsProvider(credsProvider)
.build();
//初始化httpGet
httpget=newHttpGet();
//初始化HTTP請求配置
reqestConfig=RequestConfig.custom()
.setContentCompressionEnabled(true)
.setSocketTimeout(100)
.setAuthenticationEnabled(true)
.setConnectionRequestTimeout(100)
.setConnectTimeout(100).build();
httpget.setConfig(reqestConfig);
//初始化response解析器
responseHandler=newBasicResponseHandler();
}
/*
*功能:返回響應
*@authorzhangdaquan
*@param[url]
*@returnorg.apache.http.client.methods.CloseableHttpResponse
*@exception
*/
publicstaticStringgetResponse(Stringurl)throwsIOException{
HttpGetget=newHttpGet(url);
Stringresponse=httpclient.execute(get,responseHandler);
returnresponse;
}

/*
*功能:發送http請求,并用net.sf.json工具解析
*@authorzhangdaquan
*@param[url]
*@returnorg.json.JSONObject
*@exception
*/
publicstaticJSONObjectgetUrl(Stringurl)throwsException{
try{
httpget.setURI(URI.create(url));
Stringresponse=httpclient.execute(httpget,responseHandler);
JSONObjectjson=JSONObject.fromObject(response);
returnjson;
}catch(IOExceptione){
e.printStackTrace();
}
returnnull;
}
/*
*功能:發送http請求,并用jackson工具解析
*@authorzhangdaquan
*@param[url]
*@returncom.fasterxml.jackson.databind.JsonNode
*@exception
*/
publicstaticJsonNodegetUrl2(Stringurl){
try{
httpget.setURI(URI.create(url));
Stringresponse=httpclient.execute(httpget,responseHandler);
JsonNodenode=mapper.readTree(response);
returnnode;
}catch(IOExceptione){
e.printStackTrace();
}
returnnull;
}
/*
*功能:發送http請求,并用fastjson工具解析
*@authorzhangdaquan
*@param[url]
*@returncom.fasterxml.jackson.databind.JsonNode
*@exception
*/
publicstaticcom.alibaba.fastjson.JSONObjectgetUrl3(Stringurl){
try{
httpget.setURI(URI.create(url));
Stringresponse=httpclient.execute(httpget,responseHandler);
com.alibaba.fastjson.JSONObjectjsonObject=com.alibaba.fastjson.JSONObject.parseObject(response);
returnjsonObject;
}catch(IOExceptione){
e.printStackTrace();
}
returnnull;
}

審核編輯:湯梓紅

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • HTTP
    +關注

    關注

    0

    文章

    467

    瀏覽量

    30353
  • 源碼
    +關注

    關注

    8

    文章

    576

    瀏覽量

    28635
  • 代碼
    +關注

    關注

    30

    文章

    4566

    瀏覽量

    66967
  • httpclient
    +關注

    關注

    0

    文章

    3

    瀏覽量

    1825

原文標題:高并發場景下的 HttpClient 優化方案,QPS 大大提升!

文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    【平頭哥RVB2601開發板試用體驗】基于 HTTPClient 的云語音識別 1

    前言本系列共有三篇文章,目的是在 RVB2601 上實現基于 HTTPClient 組件的云語音識別。文章連接與主要內容如下:文章1:設計思路;HTTPClient 組件測試文章2
    發表于 02-28 14:31

    【平頭哥RVB2601開發板試用體驗】基于 HTTPClient 的云語音識別 2

    本帖最后由 hazhuzhu 于 2022-2-28 20:05 編輯 前言在文章1中我們計劃用 HTTPClient 組件幫助我們與服務器通信,上傳錄音文件并接收識別結果,最終實現云語音識別
    發表于 02-28 14:50

    如何去實現基于HTTPClient云語音識別的POST請求功能呢

    如何去實現基于HTTPClient云語音識別的POST請求功能呢?有哪些步驟呢?
    發表于 03-08 08:12

    在RVB2601上怎樣去實現基于HTTPClient組件的云語音識別呢

    在RVB2601上怎樣去實現基于HTTPClient組件的云語音識別呢?有哪些實現步驟?
    發表于 03-08 07:01

    下載大文件使用HTTPClient和WiFiClient崩潰了怎么解決?

    100,000 字節的更大文件時,我遇到了崩潰。崩潰似乎發生在 GET 調用之后的一小段時間。如果我在 GET 之后注釋掉所有訪問 HTTPClient 對象的調用,我就不會崩潰。如果我只注釋掉
    發表于 02-27 06:40

    AT+HTTPCLIENT有沒有辦法打斷命令?

    版本: v2.2.0.0 ESP32-WROVER_AT_Bin_V2.2.0.0 問題描述: 1) AT+HTTPCLIENT命令看上去沒有辦法中止 有沒有辦法打斷這樣的命令? 2
    發表于 04-24 08:09

    GPRS優化思路總結報告

    GPRS優化思路總結報告:一、概述 2二、無線優化思路 2三、(E)GPRS網絡資源容量分析優化 53.1、
    發表于 07-27 21:29 ?26次下載

    GPRS優化思路總結報告_李青春

    (E)GPRS 優化思路通信網絡優化,GSM上網,PDCH,EDGEGPRS.
    發表于 01-14 15:21 ?4次下載

    win10 uwp httpClient 登陸CSDN

    我們可以使用下面代碼讓 HttpClient 使用 Cookie ,有了這個才可以保存登陸,不然登陸成功下次訪問網頁還是沒登陸。 CookieContainer cookies = new
    發表于 11-29 09:45 ?1731次閱讀

    VoLTE優化思路干貨資料下載

    電子發燒友網為你提供VoLTE優化思路干貨資料下載的電子資料下載,更有其他相關的電路圖、源代碼、課件教程、中文資料、英文資料、參考設計、用戶指南、解決方案等資料,希望可以幫助到廣大的電子工程師們。
    發表于 04-23 08:42 ?8次下載
    VoLTE<b class='flag-5'>優化</b><b class='flag-5'>思路</b>干貨資料下載

    日常網絡優化思路資料下載

    電子發燒友網為你提供日常網絡優化思路資料下載的電子資料下載,更有其他相關的電路圖、源代碼、課件教程、中文資料、英文資料、參考設計、用戶指南、解決方案等資料,希望可以幫助到廣大的電子工程師們。
    發表于 04-25 08:41 ?2次下載
    日常網絡<b class='flag-5'>優化</b><b class='flag-5'>思路</b>資料下載

    【GCC編譯優化系列】實戰分析C代碼遇到的編譯問題及解決思路

    【GCC編譯優化系列】實戰分析C工程代碼可能遇到的編譯問題及其解決思路
    的頭像 發表于 07-10 23:15 ?990次閱讀
    【GCC編譯<b class='flag-5'>優化</b>系列】實戰分析C代碼遇到的編譯問題及解決<b class='flag-5'>思路</b>

    Web前端性能優化思路

    本文旨在整理常見Web前端性能優化思路,可供前端開發參考。因為力求精簡,限于篇幅,所以并未詳述具體實施方案。 基于現代Web前端框架的應用,其原理是通過瀏覽器向服務器發送網絡請求,獲取必要
    的頭像 發表于 10-18 14:21 ?732次閱讀
    Web前端性能<b class='flag-5'>優化</b><b class='flag-5'>思路</b>

    關于手動伺服優化調整思路分享

    常規的伺服優化調整一般需要用到SERVO GUIDE 軟件,而對于一些不是很懂該軟件操作的客戶或者在現場無法進行在線聯網調整的情況下,手動調整就顯得比較關鍵實用,在此提供手動伺服優化調整思路。
    發表于 01-29 12:18 ?1597次閱讀

    如何對GPU中的矩陣乘法(GEMM)進行優化

    本篇文章是GEMM優化的第一個部分,在這篇文章中,只說優化思路和分析。
    的頭像 發表于 05-25 09:03 ?1619次閱讀
    如何對GPU中的矩陣乘法(GEMM)進行<b class='flag-5'>優化</b>
    亚洲欧美日韩精品久久_久久精品AⅤ无码中文_日本中文字幕有码在线播放_亚洲视频高清不卡在线观看
    <acronym id="s8ci2"><small id="s8ci2"></small></acronym>
    <rt id="s8ci2"></rt><rt id="s8ci2"><optgroup id="s8ci2"></optgroup></rt>
    <acronym id="s8ci2"></acronym>
    <acronym id="s8ci2"><center id="s8ci2"></center></acronym>