性能测试java协议使用httpclient方法引发的思考

转自：http://blog.csdn.net/weiweicao0429/article/details/52095932

最近手上在进行一个性能测试项目，脚本是Java语言使用httpClient实现http请求。并发用户数线程只有40个，但是服务器端启动的线程出现了400多个，是哪里平白无故出现这么多线程呢？肯定是有问题的，于是把线程的堆栈信息打印出来查看，发现大量的TIMED_WAITIND等待状态的线程。

[java] view plain copy

 print?

1. "http-bio-8058-exec-210" daemon prio=10 tid=0x00007f72a805c800 nid=0x4049 waiting on condition [0x00007f729a6b6000]  
2.    java.lang.Thread.State: TIMED_WAITING (parking)  
3.     at sun.misc.Unsafe.park(Native Method)  
4.     - parking to wait for  <0x0000000780dd6cb8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)  
5.     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)  
6.     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)  
7.     at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)  
8.     at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)  
9.     at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)  
10.     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)  
11.     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)  
12.     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)  
13.     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)  
14.     at java.lang.Thread.run(Thread.java:745)  
15.   
16.    Locked ownable synchronizers:  
17.     - None</span></span>  

第一时间就排查了服务器端是否对线程池的使用有问题，会自动生成过多的线程，经过排查并没有使用线程池的地方，于是我们转向排查是否脚本的编写问题。

脚本代码如下：

[plain] view plain copy

 print?

1. public class Actions  
2. {  
3.   
4.     public int init() throws Throwable {  
5.         return 0;  
6.     }//end of init  
7.   
8.   
9.     public int action() throws Throwable {  
10.         HttpClient client = new HttpClient();  
11.         String url = "http://xxxxx";  
12.         GetMethod method = new GetMethod(url);  
13.                   
14.         client.executeMethod(method);  
15.         System.out.println(method.getStatusLine());  
16.         String respStr1 = method.getResponseBodyAsString();  
17.         method.releaseConnection();  
18.           
19.           
20.         return 0;  
21.     }//end of action  
22.   
23.   
24.     public int end() throws Throwable {  
25.         return 0;  
26.     }//end of end  
27. }  
28. </span>  

这是一个最基础的http请求，我把脚本简化后，只操作一个http请求，检查对服务器端线程的影响。在发起40个用户后，线程达到了200多。可见问题就出现在了HttpClient的方法上。大部分人使用HttpClient都是使用类似上面的事例代码，包括Apache官方的例子也是如此。在性能测试过程中，使用HttpClient一次循环发起大量请求到服务器会使TCP连接被大量占用.

tomcat默认请求保持时间是60s,因此这样的配置就会导致每个链接至少要过60S才会被释放，这样在大量请求访问时就必然会造成链接被占满，请求等待的情况。 虽然我调用了method.releaseConnection();这个方法只是将链接返回给connection manager。如果使用HttpClient client = new HttpClient()实例化一个HttpClient connection manager默认实现是使用SimpleHttpConnectionManager。SimpleHttpConnectionManager有个构造函数如下

[java] view plain copy

 print?

1. /**  
2.  * The connection manager created with this constructor will try to keep the   
3.  * connection open (alive) between consecutive requests if the alwaysClose   
4.  * parameter is set to <tt>false</tt>. Otherwise the connection manager will   
5.  * always close connections upon release.  
6.  *   
7.  * @param alwaysClose if set <tt>true</tt>, the connection manager will always  
8.  *    close connections upon release.  
9.  */    
10. public SimpleHttpConnectionManager(boolean alwaysClose) {    
11.     super();    
12.     this.alwaysClose = alwaysClose;    
13. }    

看方法注释我们就可以看到如果alwaysClose设为true在链接释放之后connection manager 就会关闭链。在我们HttpClient client = new HttpClient()这样实例化一个client时connection manager是这样被实例化的 

[java] view plain copy

 print?

1. this.httpConnectionManager = new SimpleHttpConnectionManager();    

因此alwaysClose默认是false,connection是不会被主动关闭的，因此我们就有了一个客户端关闭链接的方法。 
方法一： 
把事例代码中的第一行实例化代码改为如下即可，在method.releaseConnection();之后connection manager会关闭connection 。

[java] view plain copy

 print?

1. HttpClient client = new HttpClient(new HttpClientParams(),new SimpleHttpConnectionManager(true) );    

方法二： 
实例化代码使用：HttpClient client = new HttpClient(); 
在method.releaseConnection();之后加上 

[java] view plain copy

 print?

1. ((SimpleHttpConnectionManager)client.getHttpConnectionManager()).shutdown();    

shutdown源代码很简单，看了一目了然 

[java] view plain copy

 print?

1. public void shutdown() {    
2.     httpConnection.close();    
3. }    

方法三： 
实例化代码使用：HttpClient client = new HttpClient(); 
在method.releaseConnection();之后加上 
client.getHttpConnectionManager().closeIdleConnections(0);此方法源码代码如下： 

[java] view plain copy

 print?

1. public void closeIdleConnections(long idleTimeout) {    
2.     long maxIdleTime = System.currentTimeMillis() - idleTimeout;    
3.     if (idleStartTime <= maxIdleTime) {    
4.         httpConnection.close();    
5.     }    
6. }    

将idleTimeout设为0可以确保链接被关闭。 
以上这三种方法都是有客户端主动关闭TCP链接的方法。下面再介绍由服务器端自动关闭链接的方法。 
方法四： 
代码实现很简单，所有代码就和最上面的事例代码一样。只需要在HttpMethod method = new GetMethod("http://www.apache.org");加上一行HTTP头的设置即可 

[java] view plain copy

 print?

1. method.setRequestHeader("Connection", "close");   

看一下HTTP协议中关于这个属性的定义： 
HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, 
       Connection: close 
现在再说一下客户端关闭链接和服务器端关闭链接的区别。如果采用客户端关闭链接的方法，在客户端的机器上使用netstat –an命令会看到很多TIME_WAIT的TCP链接。如果服务器端主动关闭链接这中情况就出现在服务器端。 
参考WIKI上的说明http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions 
The TIME_WAIT state is a protection mechanism in TCP. The side that closes a socket connection orderly will keep the connection in state TIME_WAIT for some time, typically between 1 and 4 minutes. 
TIME_WAIT的状态会出现在主动关闭链接的这一端。TCP协议中TIME_WAIT状态主要是为了保证数据的完整传输。具体可以参考此文档： 
http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7 

另外强调一下使用上面这些方法关闭链接是在我们的应用中明确知道不需要重用链接时可以主动关闭链接来释放资源。如果你的应用是需要重用链接的话就没必要这么做，使用原有的链接还可以提供性能。

所以我们可以把脚本中HttpClient client = new HttpClient();写在action外面，这样创建连接只创建一次，不用每次循环都创建一个连接。

经过验证，以上方法均有效，所以脚本的写法也会影响到我们的测试结果，所以在设计脚本的过程中，要模拟真实用户的使用场景。

另外在本次测试过程中，还对tomcat的线程配置进行了验证。在server.xml中，

[plain] view plain copy

 print?

1. <Connector port="8058" protocol="HTTP/1.1"   
2.                connectionTimeout="20000"   
3.         maxThreads="800"  
4.                redirectPort="8443" URIEncoding="utf-8"/>  

如果不配置maxThreads参数，默认是最大200线程，所以也解释了，当我把用户数并发到400时，线程数还是保持在200左右。