Sky's blog

我和我追逐的梦

常用链接

统计

其他链接

友情链接

最新评论

glassfish下的性能调优:令人极度困惑的Max Connections参数



近日做性能调优,主要是针对web service,运行于glassfish之上。前期通过修改优化代码,基本搞定一些阻碍性能的问题,主要是代码层次的不合理。

之后还是发现性能上不去,而且表现明显不合理:tps只能达到2k,而服务器cpu只停留在10%附近,压力测试的客户端cpu也不高,20%-30%吧。反复thread dump后检查无果,不论是服务器端还是客户端的工作线程都算正常,没有发现线程/锁之类的问题。分析发现主要的症状是服务器端和客户端都压不上去,服务器端工作线程很空闲,客户端则忙于socket通讯及等待服务器返回。

于是开始怀疑问题可能出现在网络通讯上,一边跑压力测试,一边用netstat命令查看socket状态,很快发现问题,有大量多大数k的socket连接出现。感觉不正常,因为应该用的是长连接,按说正常情况socket连接数应该近似等于并发的线程数。测试工具为客户端soapUI,直接连接到运行在glassfish上的web service. soapUI是支持长连接的,glassfish也是支持长连接的。

做了一下验证,只开一个工作线程,跑了几个请求,通过抓包工具发现的确是只建立了一个连接,后面的请求都是跑在同一个socket连接上。试着增加http header Connection: Keep-Alive,发现和默认没有这个参数时表现一致。故意设置为Connection: close,则每次请求都是重新建立连接。因此排除http 是短连接的问题。

继续回头看socket状态,发现出现的多达数k的socket有很多都是处于TIME_WAIT状态,只有少数处于正常的ESTABLISHED状态。TIME_WAIT意味着是服务器端主动要求close socket的,在长连接并且不断有请求的情况下,服务器为什么会如此频繁的关闭连接呢?

试着只开一个压力测试的工作线程,tps大概100+的情况下看服务器端的socket情况,很快发现问题:先是建立一个socket,ESTABLISHED状态,然后大概2s左右重新建立一个新的socket,原有的这个状态转为TIME_WAIT,之后每隔2-3秒左右,都会有上诉的情况出现----原有连接被放弃,重建新的连接。这样socket就成了1 + n的状态:1个ESTABLISHED + n个TIME_WAIT,一定时间后TIME_WAIT的socket开始逐个消失。

将压力测试的工作线程加到100之后,上述情况开始变的极度激烈,大量TIME_WAIT的socket被建立,数目直接上到1w,2w乃至36000,之后开始偶尔报错说无法连接。

问题基本就定位在这里了,为什么明明建立好了长连接,服务器端确总是会不断的关闭这些长连接导致无数的TIME_WAIT?

试着查找资料,调整参数并反复测试,最终发现和两个参数有关:

1. http.maxConnections

glassfish官网说明
https://metro.dev.java.net/guide/HTTP_Persistent_Connections__keep_alive_.html

HTTP keep-alive behavior can be controlled by the http.keepAlive (defaulttrue) and http.maxConnections (default5) system properties. For more information, see Networking Properties

进入http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html 页面查看相关的系统属性,最后聚焦在http.maxConnections :

http.maxConnections (default5)
If HTTP keep
-alive is enabled, this value is the number of idle connections that will be simultaneously kept alive, per-destination.

从说明上看,应该是max idle connection,和命名maxConnections不大符合,maxConnections感觉像是最多容许开这么多长连接。考虑默认值为5明显应该是max idle connection。

后面的测试验证,就是这个参数非常的致命,在修改为200之后,tps直接 *2。

返回来分析这个参数,默认最多容许有5个空闲长连接。考虑到100个工作线程,正常应该长连接数目也在100附近,考虑每次请求都要先申请一个连接,用完之后再放回,100个工作线程同时操作,很有可能同时将超过5个的连接返还给连接池。如果服务器简单的判断说多于5个连接然后就立即close并释放长连接,那么就会出现一方面连续释放长连接,一方面因为连接数不够不停的创建新的长连接。

换言之,当100个线程并发在连接池中进行申请连接/返还连接的过程中,连接池内的可用连接数是时刻变化的,实际的数目会有大的波动。而默认的最大空闲参数过小(默认才5)使得这个波动有极大的几率突破限制,从而造成连接池进行不必要的释放所谓过多的“空闲”连接。

glassfish中,对于这个参数的修改,非常简单,在jvm参数中增加新的一项"-Dhttp.maxConnections=250",重启即可。


2. maxKeepAliveRequests

    前面的调整,虽然达到了tps * 2的良好效果,但是使用netstat查看socket时,还是发现有非常多的TIME_TIME状态的socket,只是数目没有原来那么直上3w那么夸张,大概稳定在2000附近。

    看来还是有其他的原因的,重新回头看当时只开一个线程测试的场景:一个线程连续提交,会出现1个ESTABLISHED + n个TIME_WAIT。

    感觉上像是一个长连接上只要跑一段时间或者一定的请求,socket就会被服务器端关闭。修改测试方法,让每次请求之间等待一段时间,降低tps,发现关闭连接的时间间隔大为增加。

    后来google到maxKeepAliveRequests这个参数,对于tomcat,apache等服务器都有支持,解释如下:

maxKeepAliveRequests:
The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting 
this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.


    随即google到grizzly也有类似的系统参数可以设置这个maxKeepAliveRequests

-Dcom.sun.enterprise.web.connector.grizzly.maxKeepAliveRequests=-1

    使用关键字"glassfish maxKeepAliveRequests",发现glassfish还是有支持这个参数的,但是找不到具体设置的方法。后来在glassfish的控制台-> Configuration -> http service -> Keep Alive 下
发现了一个Max Connections参数,默认值250,解释为"Maximum number of connections in the Keep-Alive mode",和maxKeepAliveRequests似乎完全不是一回事。

    但是试着将这个参数修改为2500之后,非常惊讶的发现,见效了!单线程测试长连接释放的速度明显放慢,大体算了一下时间间隔和tpc,无论是之前的默认250还是现在新修改的2500都和测试结果
很合拍。开到100个线程测试,发现原有的2000附近的TIME_WAIT连接被降低到了大概300附近,明显改观。后面发现,可以用下面的参数直接设置:
asadmin set --user admin --passwordfile passwords.txt --port 47348 "server.http-service.keep-alive.max-connections=2500"

    这里就有点奇怪了,从测试结果来看,这个参数的表现和maxKeepAliveRequests参数的功能是一致的,但是这个参数明明叫做Max Connections,而且旁边的注释"Maximum number of connections in the Keep-Alive mode"也证明了这点。很令人费解,并且这里的Max Connections前面的http.maxConnections有重名嫌疑而作用明显不同。

下面是一个简单的列表,其他情况相同下,分别修改者两个参数前后的对比:

keep-alive.max-connections   http.maxConnections     test result     
250                                      5                                  TPS=650-700   TIME-WAIT=32600       
250                                      200                              TPS=1200        TIME-WAIT=300        
2500                                    5                                  TPS=650-700   TIME-WAIT=32600    
2500                                    200                              TPS=1200        TIME-WAIT=300  

    最终的结果,还是比较理想的,修改了上述两个参数之后,cpu终于压上去了,tps也有了巨大的提升,而且TIME_WAIT的连接也大为减少。但是这两个参数的名称,注释和实际测试中的效果,都有名不副实的感觉,令人困惑。

后续更新:
1. 经同事提醒,有新的发现,maxKeepAliveRequests得以确认

    http://docs.sun.com/app/docs/doc/820-4343/abefk?a=view
     这里是sun的官方资料,其中对
Max Connections 参数解释如下:
Max Connections

Max Connections controls the number of requests that a particular client can make over a keep
-alive connection. The range is any positive integer, and the default is 256.

Adjust 
this value based on the number of requests a typical client makes in your application. For best performance specify quite a large number, allowing clients to make many requests. 

    因此可见这个"max connections"参数的确就是通常意义上的"maxKeepAliveRequests"。这里sun的命名不大合适,容易造成误解。

posted on 2010-04-29 17:10 sky ao 阅读(6372) 评论(1)  编辑  收藏 所属分类: web service

评论

# re: glassfish下的性能调优:令人极度困惑的Max Connections参数 2010-04-30 12:02 99书城

案件快速的既骄傲  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航: