HttpClient出现大量time_wait问题】的更多相关文章

在高并发短连接的TCP服务器上,当服务器处理完请求后立刻主动正常关闭连接.这个场景下会出现大量socket处于TIME_WAIT状态.如果客户端的并发量持续很高,此时部分客户端就会显示连接不上.我来解释下这个场景.主动正常关闭TCP连接,都会出现TIMEWAIT. 为什么我们要关注这个高并发短连接呢?有两个方面需要注意:1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了.2. 在这个场景中,短连接表示“业务…
http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions 1. Connections in TIME_WAIT State After running your HTTP application, you use the netstat command and detect a lot of connections in stateTIME_WAIT. Now you wonder wh…
结论: 如果使用httpclient 3.1并发量比较大的项目,最好升级到httpclient4.2.3上,保证并发量大时能抗住.httpclient 4.3.3,目前还有一些bug:还是用4.2.x稳定版本吧.   以库存项目为例: httpclient一天并发量在1500w左右,峰值一秒7万. 在之前使用过程中,一直存在大量的 org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection…
HttpClient client = new HttpClient(); HttpMethod method = new GetMethod("http://www.apache.org"); try { client.executeMethod(method); byte[] responseBody = null; responseBody = method.getResponseBody(); } catch (HttpException e) { // TODO Auto-g…
修改Time_Wait和CLOSE_WAIT时间 修改Time_Wait参数的方法 (在服务端修改)Windows下在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters,添加名为TcpTimedWaitDelay的DWORD键,设置为30,以缩短TIME_WAIT的等待时间 解决CLOSE_WAIT的方法:(在客户端修改)1 一般原因都是TCP连接没有调用关闭方法.需要应用来处理网络链接关闭.2 对于Web请…
转自: http://blog.csdn.net/shootyou/article/details/6615051 今天解决了一个HttpClient的异常,汗啊,一个HttpClient使用稍有不慎都会是毁灭级别的啊. 这里有之前因为route配置不当导致服务器异常的一个处理:http://blog.csdn.net/shootyou/article/details/6415248 里面的HttpConnectionManager实现就是我在这里使用的实现. 问题表现: tomcat后台日志发…
在服务器的日常维护过程中,会经常用到下面的命令: netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 它会显示例如下面的信息: TIME_WAIT 814CLOSE_WAIT 1FIN_WAIT1 1ESTABLISHED 634SYN_RECV 2LAST_ACK 1 常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭. 具体每种状态什…
using (HttpClient client = new HttpClient()){} 每次发起http请求每次new httpClient,它会打开许多套接字,比你实际的需求多许多,这极大地增加了服务器的负载.而且,这些套接字实际上不会被using语句关闭.相反,它们是在应用程序停止使用它们几分钟之后才会关闭. 当你销毁它时,它就启动一个进程,关闭在它控制之下的套接字.也就是说,你下次请求连接时,必须重复整个连接新建过程.如果网络延迟很高,或者连接是受保护的(需要新一轮的SSL/TLS协…
1.背景 我们有个业务,会调用其他部门提供的一个基于http的服务,日调用量在千万级别.使用了httpclient来完成业务.之前因为qps上不去,就看了一下业务代码,并做了一些优化,记录在这里. 先对比前后:优化之前,平均执行时间是250ms:优化之后,平均执行时间是80ms,降低了三分之二的消耗,容器不再动不动就报警线程耗尽了,清爽~ 2.分析 项目的原实现比较粗略,就是每次请求时初始化一个httpclient,生成一个httpPost对象,执行,然后从返回结果取出entity,保存成一个字…
最近,公司的接口服务器(客户端,向外发送数据)频繁出现了connect timeout 以及readtime out 的情况,经过运维平台检测,并没有网络延时的情况.于是,开始怀疑连接池出了问题. 使用linux命令: netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  可以清楚的看到tcp各个状态下的连接数. 如图: CLOSE_WAIT 数目大的惊人,问题就出在了这里:这个级别的TIME_WAIT是没有问…