昨天的搜索系统又出状况了，几个库同时重建索引变得死慢。经过一个上午的复现分析，确定问题出现httpclient的使用上（我使用的是3.1这个被广泛使用的遗留版本）。搜索系统在重建索引时，是并发多个线程（默认是8个）不停的从PHP客户端取数据（当然，从另一个角度来说，搜索系统是客户端，PHP端是服务端），取回后放到一个队列里由单独的一个或多个线程更新索引。在测试环境复现发现，对于一个请求，PHP端打印耗时是1-2秒，但搜索端打印在4-6秒。这种耗时差别也就两种可能性，一个是PHP端返回到搜索端接受完耗时太长，另一个就是搜索端在真正发给PHP端数据前等待了很久。因为有了之前的jetty7的困顿，起初我怀疑是传输数据的问题。因为请求数据的代码部分我只是简单的使用了httpclient，所以只能从httpclient着手分析。我想到把PHP端和搜索端的请求起始和结束时间都打出来对照一下，不过在这样做之前我把搜索端的并发请求线程数调到了1,看下单线程情况下效果如何，结果惊奇地发现PHP端和搜索端的耗时相近。所以，可以确定，是httpclient的并发连接处理上可能存在问题。不消说，翻开httpclient API中和配置相关的接口，结果找到HttpConnectionManagerParams类中下面两个函数：
public void setDefaultMaxConnectionsPerHost(int maxHostConnections); public void setMaxTotalConnections(int maxTotalConnections);
httpclient在处理请求连接方面使用了连接池，它内部实际上有两种连接池，一种是全局的ConnectionPool，一种是每主机（per-host）HostConnectionPool。参数maxHostConnections就HostConnectionPool中表示每主机可保持连接的连接数，maxTotalConnections是ConnectionPool中可最多保持的连接数。每主机的配置类是HostConfiguration，HttpClient有个int executeMethod(final HostConfiguration hostConfiguration, final HttpMethod method)方法可以指定使用哪个HostConfiguration，不过多数情况都是不显示指定HostConfiguration，这样httpclient就用了默认的HostConfiguration=null，也就是说所有的请求可以认为指自同一个主机。如果不设置这两个参数，httpclient自然会用默认的配置，也就是MultiThreadedHttpConnectionManager中的：
public static final int DEFAULT_MAX_HOST_CONNECTIONS = 2; // Per RFC 2616 sec 8.1.4 ? public static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 20;
默认的maxHostConnections大小只有2,也就是说，在我并发8个线程请求数据时，实际上会有6个线程处于等待被调度,这也就解释上面的现象了。再看看上面的注释，我从http://www.faqs.org/rfcs/rfc2616.html找到从了RFC 2616 sec 8.1.4 Practical Considerations段落的最后一段：
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
看这叙述，也就表明人家httpclient设置maxHostConnections为2是有根有据的。不过，这种设置显然适合的是浏览器这种客户端，但我相信，多数使用httpclient并不希望有这种默认的限制。而它默认的只有20的maxTotalConnections也太有些吝啬了。我后来浏览solr的客户端server类CommonsHttpSolrServer的代码发现了下面的段落，solr要比我更了解httpclient：
_httpClient = (client == null) ? new HttpClient(new MultiThreadedHttpConnectionManager()) : client; if (client == null) { // set some better defaults if we created a new connection manager and client // increase the default connections this.setDefaultMaxConnectionsPerHost( 32 ); // 2 this.setMaxTotalConnections( 128 ); // 20 }
对于httpclient，特别指出的是它的MultiThreadedHttpConnectionManager，看名字好像是多线程并发请求似的，其实不是，但它也确实用到了多线程，那是在发现连接不够用时起个等待线程wait信号，这个名称的含义应该是多线程情况线程安全的HttpConnectionManager。
使用httpclient还有两点经验，一个是创建的MultiThreadedHttpConnectionManager 实例最好是全局的，否则会有多个连接池，而HttpClient是线程安全的，可以多个实例。另一个是，在处理请求的最后，也就是finnaly里中，要调用method.releaseConnection();回收连接，否则连接池就可能会爆了。
补充：写完之后倒在床上，我又想起了几个问题，这里补充上：
1、系统原先重建索引隐约记得速度还是可以的，为什么现在变慢得如此明显？这有两方面的原因，一个是原来系统取数据是用的单线程（我后来发现单取数据取数据速度跟不上更新索引的速度所以改成多线程），另一个是，当时重建没有一下子同时开启数个库。所以，即便是同样的代码，环境变了，效果也可能变了。当这种改变悄然发生了，程序员却没有捕捉到，才会第一直觉感到问题的诡异。
2、对于长时间不能获得连接的情况，httpclient是否有warn日志报出来？因为我使用了httpclient的getResponseBodyAsStream方法，而它会打出warn日志，所以我是关掉了httpclient的warn级别的。所以，我又检查了httpclient的代码，可惜没看到相关warning log，这点httpclient可以改进下。不过httpclient现在都是4时代了，而我使用的还是3.1的，而3.x已经被停止更新了，所以再采用httpclient可以考虑4版本的，尽管现在能见到的代码几乎都是用的3.x系列的。
3、httpclient的文档是否有特别提到连接数配置的情况？我翻看了一下，确实在关于threading一页中有提到。不过，我等使用它时显然没有完整阅毕它的文档。或许，httpclient给出个明显的最佳实践到能引起使用者的注意，否则误用的情况还是会时有发生。不信，google之。