高并发场景下的 HttpClient 优化，QPS 大大提升！

Posted 2023-05-08 Java技术栈

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了高并发场景下的 HttpClient 优化，QPS 大大提升！相关的知识，希望对你有一定的参考价值。

HttpClient优化思路：

池化
长连接
httpclient和httpget复用
合理的配置参数（最大并发请求数，各种超时时间，重试次数）
异步 6、多读源码

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的开销

原本的逻辑里，使用了如下代码：

HttpEntity entity = httpResponse.getEntity();
String response = EntityUtils.toString(entity);

这里我们相当于额外复制了一份content到一个字符串里，而原本的httpResponse仍然保留了一份content，需要被consume掉，在高并发且content非常大的情况下，会消耗大量内存。并且，我们需要显式的关闭连接，ugly。

3.实现

按上面的分析，我们主要要做三件事：一是单例的client，二是缓存的保活连接，三是更好的处理返回结果。一就不说了，来说说二。

提到连接缓存，很容易联想到数据库连接池。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如下：

ConnectionKeepAliveStrategy myStrategy = new ConnectionKeepAliveStrategy() 
    @Override
    public long getKeepAliveDuration(HttpResponse response, HttpContext context) 
        HeaderElementIterator it = new BasicHeaderElementIterator
            (response.headerIterator(HTTP.CONN_KEEP_ALIVE));
        while (it.hasNext()) 
            HeaderElement he = it.nextElement();
            String param = he.getName();
            String value = he.getValue();
            if (value != null && param.equalsIgnoreCase
               ("timeout")) 
                return Long.parseLong(value) * 1000;
            
        
        return 60 * 1000;//如果没有约定，则默认定义时长为60s
    
;

3.2 配置一个PoolingHttpClientConnectionManager

PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
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方法，如下所示。

public static class IdleConnectionMonitorThread extends Thread 
    
    private final HttpClientConnectionManager connMgr;
    private volatile boolean shutdown;
    
    public IdleConnectionMonitorThread(HttpClientConnectionManager connMgr) 
        super();
        this.connMgr = connMgr;
    
 
    @Override
    public void run() 
        try 
            while (!shutdown) 
                synchronized (this) 
                    wait(5000);
                    // Close expired connections
                    connMgr.closeExpiredConnections();
                    // Optionally, close connections
                    // that have been idle longer than 30 sec
                    connMgr.closeIdleConnections(30, TimeUnit.SECONDS);
                
            
         catch (InterruptedException ex) 
            // terminate
        
    
    
    public void shutdown() 
        shutdown = true;
        synchronized (this) 
            notifyAll();

3.4 使用httpclient执行method时降低开销

这里要注意的是，不要关闭connection。

一种可行的获取内容的方式类似于，把entity里的东西复制一份：

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

但是，更推荐的方式是定义一个ResponseHandler，方便你我他，不再自己catch异常和关闭流。在此我们可以看一下相关的源码：

public <T> T execute(final HttpHost target, final HttpRequest request,
            final ResponseHandler<? extends T> responseHandler, final HttpContext context)
            throws IOException, ClientProtocolException 
        Args.notNull(responseHandler, "Response handler");
 
        final HttpResponse response = execute(target, request, context);
 
        final T result;
        try 
            result = responseHandler.handleResponse(response);
         catch (final Exception t) 
            final HttpEntity entity = response.getEntity();
            try 
                EntityUtils.consume(entity);
             catch (final Exception t2) 
                // Log this exception. The original exception is more
                // important and will be thrown to the caller.
                this.log.warn("Error consuming content after an exception.", t2);
            
            if (t instanceof RuntimeException) 
                throw (RuntimeException) t;
            
            if (t instanceof IOException) 
                throw (IOException) t;
            
            throw new UndeclaredThrowableException(t);
        
 
        // Handling the response was successful. Ensure that the content has
        // been fully consumed.
        final HttpEntity entity = response.getEntity();
        EntityUtils.consume(entity);//看这里看这里
        return result;

可以看到，如果我们使用resultHandler执行execute方法，会最终自动调用consume方法，而这个consume方法如下所示：

public static void consume(final HttpEntity entity) throws IOException 
        if (entity == null) 
            return;
        
        if (entity.isStreaming()) 
            final InputStream instream = entity.getContent();
            if (instream != null) 
                instream.close();

可以看到最终它关闭了输入流。

4.其他

通过以上步骤，基本就完成了一个支持高并发的httpclient的写法，下面是一些额外的配置和提醒：

4.1 httpclient的一些超时配置

CONNECTION_TIMEOUT是连接超时时间，SO_TIMEOUT是socket超时时间，这两者是不同的。连接超时时间是发起请求前的等待时间；socket超时时间是等待数据的超时时间。

HttpParams params = new BasicHttpParams();
//设置连接超时时间
Integer CONNECTION_TIMEOUT = 2 * 1000; //设置请求超时2秒钟 根据业务调整
Integer SO_TIMEOUT = 2 * 1000; //设置等待数据超时时间2秒钟 根据业务调整
 
//定义了当从ClientConnectionManager中检索ManagedClientConnection实例时使用的毫秒级的超时时间
//这个参数期望得到一个java.lang.Long类型的值。如果这个参数没有被设置，默认等于CONNECTION_TIMEOUT，因此一定要设置。
Long CONN_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(new DefaultHttpRequestRetryHandler(0, false));

4.2 如果配置了nginx的话，nginx也要设置面向两端的keep-alive

现在的业务里，没有nginx的情况反而比较稀少。nginx默认和client端打开长连接而和server端使用短链接。注意client端的keepalive_timeout和keepalive_requests参数，以及upstream端的keepalive参数设置，这三个参数的意义在此也不再赘述。

以上就是我的全部设置。通过这些设置，成功地将原本每次请求250ms的耗时降低到了80左右，效果显著。

JAR包如下：

<!-- httpclient -->
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.6</version>
</dependency>

代码如下：

//Basic认证
private static final CredentialsProvider credsProvider = new BasicCredentialsProvider();
//httpClient
private static final CloseableHttpClient httpclient;
//httpGet方法
private static final HttpGet httpget;
//
private static final RequestConfig reqestConfig;
//响应处理器
private static final ResponseHandler<String> responseHandler;
//jackson解析工具
private static final ObjectMapper mapper = new ObjectMapper();
static 
    System.setProperty("http.maxConnections","50");
    System.setProperty("http.keepAlive", "true");
    //设置basic校验
    credsProvider.setCredentials(
            new AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, AuthScope.ANY_REALM),
            new UsernamePasswordCredentials("", ""));
    //创建http客户端
    httpclient = HttpClients.custom()
            .useSystemProperties()
            .setRetryHandler(new DefaultHttpRequestRetryHandler(3,true))
            .setDefaultCredentialsProvider(credsProvider)
            .build();
    //初始化httpGet
    httpget = new HttpGet();
    //初始化HTTP请求配置
    reqestConfig = RequestConfig.custom()
            .setContentCompressionEnabled(true)
            .setSocketTimeout(100)
            .setAuthenticationEnabled(true)
            .setConnectionRequestTimeout(100)
            .setConnectTimeout(100).build();
    httpget.setConfig(reqestConfig);
    //初始化response解析器
    responseHandler = new BasicResponseHandler();

/*
 * 功能：返回响应
 * @author zhangdaquan
 * @date 2019/1/3 上午11:19
 * @param [url]
 * @return org.apache.http.client.methods.CloseableHttpResponse
 * @exception
 */
public static String getResponse(String url) throws IOException 
    HttpGet get = new HttpGet(url);
    String response = httpclient.execute(get,responseHandler);
    return response;

 
/*
 * 功能：发送http请求，并用net.sf.json工具解析
 * @author zhangdaquan
 * @date 2018/8/15 下午2:21
 * @param [url]
 * @return org.json.JSONObject
 * @exception
 */
public static JSONObject getUrl(String url) throws Exception
    try 
        httpget.setURI(URI.create(url));
        String response = httpclient.execute(httpget,responseHandler);
        JSONObject json = JSONObject.fromObject(response);
        return json;
     catch (IOException e) 
        e.printStackTrace();
    
    return null;

/*
 * 功能：发送http请求，并用jackson工具解析
 * @author zhangdaquan
 * @date 2018/12/24 下午2:58
 * @param [url]
 * @return com.fasterxml.jackson.databind.JsonNode
 * @exception
 */
public static JsonNode getUrl2(String url)
    try 
        httpget.setURI(URI.create(url));
        String response = httpclient.execute(httpget,responseHandler);
        JsonNode node = mapper.readTree(response);
        return node;
     catch (IOException e) 
        e.printStackTrace();
    
    return null;

/*
 * 功能：发送http请求，并用fastjson工具解析
 * @author zhangdaquan
 * @date 2018/12/24 下午2:58
 * @param [url]
 * @return com.fasterxml.jackson.databind.JsonNode
 * @exception
 */
public static com.alibaba.fastjson.JSONObject getUrl3(String url)
    try 
        httpget.setURI(URI.create(url));
        String response = httpclient.execute(httpget,responseHandler);
        com.alibaba.fastjson.JSONObject jsonObject = com.alibaba.fastjson.JSONObject.parseObject(response);
        return jsonObject;
     catch (IOException e) 
        e.printStackTrace();
    
    return null;

原文：blog.csdn.net/u010285974/article/details/85696239

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装饰器模式，这才是优雅的方式！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！

HttpClient在高并发场景下的优化实战

在项目中使用HttpClient可能是很普遍,尤其在当下微服务大火形势下,如果服务之间是http调用就少不了跟http客户端找交道.由于项目用户规模不同以及应用场景不同,很多时候可能不需要特别处理也.然而在一些高并发场景下必须要做一些优化.

项目是快递公司的快件轨迹查询项目,目前平均每小时调用量千万级别.轨迹查询以Oracle为主要数据源,Mongodb为备用,当Oracle不可用时,数据源切换到Mongodb.今年菜鸟团队加入后,主要数据迁移到了阿里云上,以Hbase为主要存储.其中Hbase数据查询服务由数据解析组以Http方式提供.原有Mongodb弃用,云上数据源变为主数据源,Oracle作为备用.当数据源切换以后,主要的调用方式也就变成了http方式.在第10月初第一轮双11压测试跑上,qps不达标.当然这个问题很好定位,因为十一假之间轨迹域组内已经进行过试跑,当时查的是oracle.十一假期回来后,只有这一处明显的改动,很容易定位到问题出现在调用上.但具体是云上Hbase慢,还是网络传输问题(Hbase是阿里云上的服务,轨迹查询项目部署在IDC机房).通过云服务,解析组和网络运维的配合,确定问题出现在应用程序上.在Http服务调用处打日志记录,发现以下问题:

技术图片

可以看到每隔一段时间,就会有不少请求的耗时明显比其它的要高.

导致这种情况可能可能是HttpClient反复创建销毁造成引起来销,首先凭经验可能是对HttpClient进行了Dispose操作(Using(HttpClient client=new HttpClient){...})

如果你装了一些第三方插件,当你写的HttpClient没有被Using包围的时候会给出重构建议,建议加上Using或者手动dispose.然而实际中是否要dispose还要视情况而定,对于一般项目大家的感觉可能是不加也没有大问题,加了也还ok.但是实际项目中,一般不建议反复重新创建这个对象,关于HttpClient是否需要Dispose请看这里

在对这个问题的答案里,提问者指出微软的一些示例也是没有使用using的.下面一个比较热的回答指出HttpClient生命周期应该和应用程序生命周期一致,只要应用程序需要Http请求,就不应用把它Dispose掉.下面的一个仍然相对比较热的回答指出一般地,带有Dispose方法的对象都应当被dispose掉,但是HttpClient是一个例外.

当然以上只是结合自己的经验对一个大家都可能比较困惑的问题给出一个建议,实际上对于一般的项目,用还是不用Dispose都不会造成很大问题.本文中上面提到的问题跟HttpClient也没有关系,因为程序中使用的Http客户端是基于HttpWebRequest封装的.

问题排查及优化

经过查询相关资料以及同行的经验分享(这篇文章给了很大启发)

查看代码,request.KeepAlive = true;查询微软相关文档,这个属性其实是设置一个‘Keep-alive‘请求header,当时同事封装Http客户端的场景现场无从得知,然而对于本文中提到的场景,由于每次请求的都是同一个接口,因此保持持续连接显然能够减少反复创建tcp连接的开销.因此注释掉这一行再发布测试,以上问题便不复出现了!

当然实际中做的优化绝不仅仅是这一点,如果仅仅是这样,一句话就能够说完了,大家都记住以后就这样做就Ok了.实际上还参考了不少大家在实际项目中的经验或者坑.下面把整个HttpClient代码贴出来,下面再对关键部分进行说明.

 public static string Request(string requestUrl, string requestData, out bool isSuccess, string contentType = "application/x-www-form-urlencoded;charset=utf8")
    {
        string apiResult = "";
        isSuccess = false;
        if (string.IsNullOrEmpty(requestData))
        {
            return apiResult;
        }
        HttpWebRequest request = null;
        HttpWebResponse response = null;
        try
        {
            byte[] buffer = Encoding.UTF8.GetBytes(requestData);
            request = WebRequest.Create($"{requestUrl}") as HttpWebRequest;
            request.ContentType = "application/json";
            request.Method = "POST";
            request.ContentLength = buffer.Length;
            request.Timeout =200;
            request.ReadWriteTimeout =  Const.HttpClientReadWriteTimeout
            request.ServicePoint.Expect100Continue = false;
            request.ServicePoint.UseNagleAlgorithm = false;
            request.ServicePoint.ConnectionLimit = 2000
            request.AllowWriteStreamBuffering = false;
            request.Proxy = null;

            using (var stream = request.GetRequestStream())
            {
                stream.Write(buffer, 0, buffer.Length);
            }
            using (response = (HttpWebResponse)request.GetResponse())
            {
                string encoding = response.ContentEncoding;
                using (var stream = response.GetResponseStream())
                {
                    if (string.IsNullOrEmpty(encoding) || encoding.Length < 1)
                    {
                        encoding = "UTF-8"; //默认编码
                    }

                    if (stream != null)
                    {
                        using (StreamReader reader = new StreamReader(stream, Encoding.GetEncoding(encoding)))
                        {
                            apiResult = reader.ReadToEnd();
                            //byte[] bty = stream.ReadBytes();
                            //apiResult = Encoding.UTF8.GetString(bty);
                        }
                    }
                    else
                    {
                        throw new Exception("响应流为null!");
                    }
                }
            }
            isSuccess = true;
        }
        catch (Exception err)
        {
            isSuccess = false;
            LogUtilities.WriteException(err);
        }
        finally
        {
            response?.Close();
            request?.Abort();
        }

        return apiResult;
    }

首先是TimeOut问题,不仅仅是在高并发场景下,实际项目中建议不管是任何场景都要设置它的值.在HttpWebRequest对象中,它的默认值是100000毫秒,也就是100秒.如果服务端出现问题,默认设置将会造成严重阻塞,对于普通项目也会严重影响用户体验.返回失败让用户重试也比这样长时间等待体验要好.
ReadWriteTimeout很多朋友可能没有接触过这个属性,尤其是使用.net 4.5里HttpClient对象的朋友.有过Socket编程经验的朋友可能会知道,socket连接有连接超时时间和传输超时时间,这里的ReadWriteTimeout类似于Socket编程里的传输超时时间.从字面意思上看,就是读写超时时间,防止数据量过大或者网络问题导致流传入很长时间都无法完成.当然在一般场景下大家可以完全不理会它,如果由于网络原因造成读写超时也很有可能造成连接超时.这里之所以设置这个值是由于实际业务场景决定的.大家可能已经看到,以上代码对于ReadWriteTimeout的设置并不像Timeout一样设置为一个固定值,而是放在了一个Const类中,它实际上是读取一个配置,根据配置动态决定值的大小.实际中的场景是这样的,由于压测环境无法完全模拟真实的用户访问场景.压测的时候都是使用单个单号进行轨迹查询,但是实际业务中允许用户一次请求查询最多多达数百个单号.一个单号的轨迹记录一般都是几十KB大小,如果请求的单号数量过多数量量就会极大增加长,查询时间和传输时间都会极大增加,为了保证双11期间大多数用户能正常访问,必要时会把这个时间设置的很小(默认是3000毫秒),让单次查询量大的用户快速失败.

以上只是一种备用方案,不得不承认,既然系统允许一次查询多个单号,因此在用户在没有达到上限之前所有的请求都是合法的,也是应该予以支持的,因此以上做法实际上有损用户体验的,然而系统的资源是有限的,要必要的时候只能牺牲特殊用户的利益,保证绝大多数用户的利益.双11已经渡过,实际中双11也没有改动以上配置的值,但是做为风险防范增加动态配置是必要的.

这里再多差一下嘴,就是关于ContentLength它的值是可以不设置的,不设置时程序会自动计算,但是设置的时候一定要设置字节数组的长度,而不是字符串的长度,因为包含中文时,根据编码规则的不同,中文字符可能占用两个字节或者更长字节长度.

关于 request.ServicePoint.Expect100Continue = false; request.ServicePoint.UseNagleAlgorithm = false;这两项笔者也不是特别清楚,看了相关文档也没有特别明白,还请了解的朋友指点,大家共同学习进步.
request.ServicePoint.ConnectionLimit = 2000是设置最大的连接数,不少朋友是把这个数值设置为65536,实际上单台服务器web并发连接远太不到这个数值.这里根据项目的实际情况,设置为2000.以防止处理能力不足时,请求队列过长.
request.AllowWriteStreamBuffering = false;根据[微软文档(https://docs.microsoft.com/zh-cn/dotnet/api/system.net.httpwebrequest.allowwritestreambuffering?redirectedfrom=MSDN&view=netframework-4.8#System_Net_HttpWebRequest_AllowWriteStreamBuffering)]这个选项设置为true时,数据将缓冲到内存中，以便在重定向或身份验证请求时可以重新发送数据.

最为重要的是,文档中说将 AllowWriteStreamBuffering 设置为 true 可能会在上传大型数据集时导致性能问题，因为数据缓冲区可能会使用所有可用内存。由于发送的请求仅仅是单号,数据量很小,并且很少有用户一个单号反复查询的需求.加上可能会有副作用.这里设置为false.

request.Proxy = null;这里是参考了一个一位网友的文章,里面提到默认的Proxy导致超时怪异行为.由于解决问题是在10月份,据写这篇文章已经有一段时间了,因此再寻找时便找不到这篇文章了.有兴趣的朋友可以自己搜索一下.

很多朋友可能会关心,通过以上配置到底有没有解决问题.实际中以上配置后已经经历了双11峰值qps过万的考验.下面给出写本文时候请求耗时的监控

技术图片

可以看到,整体上请求耗时比较平稳.

可能看了这个图,有些朋友还是会有疑问,通过上面日志截图可以看到,除了耗时在100ms以上的请求外,普通的耗时在四五十毫秒的还是有很多的,但是下面这个截图里都是在10到20区间浮动,最高的也就30ms.这其实是由于在压测的过程中,发现Hbase本身也有不稳定的因素(大部分请求响应耗时都很平稳,但是偶尔会有个别请求娄千甚至数万毫秒(在监控图上表现为一个很突兀的线,一般习惯称为毛刺),这在高并发场景下是不能接受的,问题反馈以后阿里云对Hbase进行了优化,优化以后耗时也有所下降.)

以上是关于高并发场景下的 HttpClient 优化，QPS 大大提升！的主要内容，如果未能解决你的问题，请参考以下文章

HttpClient在高并发场景下的优化实战

双十一高并发场景背后的数据库RDS技术揭秘

HttpClient对高并发有啥优化吗

高并发场景下的限流策略

HttpClient 在vivo内销浏览器的高并发实践优化

斗鱼基于 Golang 在高并发场景下的日志系统实践