高并发场景下HttpClient的优化使用

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非常合适