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 左右, 效果显著
完
来源: https://www.cnblogs.com/bethunebtj/p/8493379.html