http接口性能优化(网关性能优化)

1、背景


Webgate服务在联调期间,发现用户请求无响应的问题。现象:Webgate服务在启动后,随着用户请求不断的访问(用户通过浏览器发送请求),一段时间后,发现请求开始打转(菊花^_^),没有返回。服务重启后正常,访问一段时间又重现。

小贴士:Webgate是个什么服务?

Webgate是基于zuul1.0实现的网关服务,包括了鉴权、限流、熔断、负载均衡、http请求转发等功能。核心就是请求路由,即http请求转发。

服务模块调用示意图

http接口性能优化(网关性能优化)(1)

2、结论先行


经过一系列的排查定位到由于http连接池相关参数设置不合理及http异常请求连接没释放,从而导致连接数耗尽,出现了请求打转的现象。

看了服务部署图、问题小伙伴是不是会有如下的疑问呢:

①请求无响应如何定位到是Webgate的问题,不是BussApp的问题?

②Webgate这么多功能,如何定位到是http连接池的问题呢?

那么下边我们将重现如何定位问题及解决问题的过程。

3、定位过程


1、逐一排除法,缩小问题范围,确定问题服务。

通过服务调用模块示意图,我们知道当用户浏览器端无响应时,要么是Webgate的问题,要么是BussApp的问题。在通过webgate访问出问题后,直接访问BussApp是可用的,那么很快可以定位到是webgate出了问题。解释了疑问①

2、聚焦问题服务,查看日志有无明确提示。

确定了是webgate的问题后,继续深入查看导致webgate服务无响应的原因:

首先查看日志,无可疑异常日志打印。

3、根据现象猜测可能原因,逐一排除,确定问题代码。

猜测可能的原因:

  • 怀疑线程进入死循环了,查看了cpu。发现cpu的每个核利用率均不高。
  • 查看系统资源利用情况 cpu io mem net均正常。
  • 怀疑full gc?查看,发现也没有full gc。(full gc产生会导致应用程序暂停响应)
  • 怀疑线程等待、阻塞了、死锁 查看堆栈信息(jstack)。如图发现了问题。

http接口性能优化(网关性能优化)(2)

WAITING 状态的线程 ,发现在运行到SaaSLoadBalancinghttpclient.execute() 时等待了。这个时候就欣喜了 。这个是应用的代码发送http请求。

继续往上看

at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseconnection

很明显是去连接池获取连接对象,到此我们定位到是http连接池的问题了。

小贴士:

深入思考的小伙伴会问 几千行的堆栈信息里 你是怎么找到的?

其实只要对 Java的线程的生命周期,及线程的每个状态理解透彻了,也就知道在什么情况下该关心什么状态的线程。

再比如:有个CPU使用率100% ,那需要关注什么状态的线程答案是:RUNNABLE

4、聚焦问题代码,深挖原因。

为什么会一直等待呢? 框架中我们使用了http连接池[了解http连接池的原理]

如图连接池的一个结构图,关于连接池如何建立连接、分配连接、回收连接、保持连接这里暂不进行说明。

http接口性能优化(网关性能优化)(3)

小贴士:了解下http连接池的三个超时时间相关参数

connectionRequestTimeout

#设置从connect Manager获取Connection 超时时间,单位毫秒。这个属性是新加的属性,因为目前版本是可以共享连接池的。需要设置,默认-1.无限长等待。默认为-1,意味着无限大,就是一直阻塞等待。 从连接池中获取连接的超时时间,超过该时间未拿到可用连接, * 会抛出org.apache.http.conn.ConnectionPoolTimeoutException:Timeout waiting for connection from pool

#设置建议 设置500ms即可,不要设置太大,这样可以使连接池连接不够时不用等待太久去获取连接,不要让大量请求堆积在获取连接处,尽快抛出异常,发现问题。

connectTimeout

#连接上服务器(握手成功)的时间,超出该时间抛出connecttimeout

#设置建议:根据网络情况,内网、外网等,可设置连接超时时间为2秒,具体根据业务调整

socketTimeout

#服务器返回数据(response)的时间,超过该时间抛出read timeout

#设置建议:需要根据具体请求的业务而定,如请求的API接口从接到请求到返回数据的平均处理时间为1秒,那么读超时时间可以设置为2秒,考虑并发量较大的情况,也可以通过性能测试得到一个相对靠谱的值。socketTimeout有默认值,也可以针对每个请求单独设置。

查看我们代码发现第一个参数没有设置 ,所以一直等待。设置超时时间为500毫秒

builder.setConnectionRequestTimeout(500);

设置超时时间 ,连接用完后。查看日志抛出异常

org.apache.http.conn.ConnectionPoolTimeoutException: Timeoutwaiting for connection from pool

为什么从连接池里get 不到connection对象?池连接数太小,还是连接数耗尽了?

小贴士:看http连接池的其它几个连接相关参数

maxConnTotal

#maxConnTotal 是整个连接池的大小,根据自己的业务需求进行设置

maxConnPerRoute

#是单个路由连接的最大数,可以根据自己的业务需求进行设置。比如maxConnTotal =200,maxConnPerRoute =100,那么,如果只有一个路由的话,那么最大连接数也就是100了;如果有两个路由的话,那么它们分别最大的连接数是100,总数不能超过200

#Http连接参数设置建议:


根据“利尔特法则”可以得到简单的公式:

http接口性能优化(网关性能优化)(4)

简单地说,利特尔法则解释了这三种变量的关系:L—系统里的请求数量、λ—请求到达的速率、W—每个请求的处理时间。例如,如果每秒10个请求到达,处理一个请求需要1秒,那么系统在每个时刻都有10个请求在处理。如果处理每个请求的时间翻倍,那么系统每时刻需要处理的请求数也翻倍为20,因此需要20个线程。连接池的大小可以参考 L。

qps指标可以作为“λ—请求到达的速率”,由于httpClient是作为http客户端,故需要通过一些监控手段得到服务端集群访问量较高时的qps,如客户端集群为4台,服务端集群为2台,监控到每台服务端机器的qps为100,如果每个请求处理时间为1秒,那么2台服务端每个时刻总共有 100 * 2 * 1s = 200 个请求访问,平均到4台客户端机器,每台要负责50,即每台客户端的连接池大小可以设置为50。

当然实际的情况是更复杂的,上面的请求平均处理时间1秒只是一种业务的,实际情况的业务情况更多,评估请求平均处理时间更复杂。所以在设置连接数后,最好通过比较充分性能测试验证是否可以满足要求。

还有一些Linux系统级的配置需要考虑,如单个进程能够打开的最大文件描述符数量open files默认为1024,每个与服务端建立的连接都需要占用一个文件描述符,如果open files值太小会影响建立连接。

还要注意,连接数主要包含maxTotal-连接总数、maxPerRoute-路由最大连接数,尤其是maxPerRoute默认值为5,很小,设置不好的话即使maxTotal再大也无法充分利用连接池。


默认设置的小 10 和 5,然后调大 ,只是推迟了服务挂的时间。

打开http连接池的debug日志 ,发现httpclient大部分能正常回收 但是可用的越来越少 ,当可用为0 就是服务不可用的时候。

2018-08-09 16:37:10,465 DEBUG PoolingHttpClientConnectionManager:288 - Connection leased:[id: 98474][route:{}->http://tenantweb-prd1.ypubtanent.svc.gz.n.jd.local:80][total kept alive:0; route allocated: 2 of 50; totalallocated: 2 of 200] 2018-08-09 16:37:10,497 DEBUG PoolingHttpClientConnectionManager:326 - Connection released: [id:98474][route: {}->http://tenantweb-prd1.ypubtanent.svc.gz.n.jd.local:80][totalkept alive: 0; route allocated: 1 of 50;total allocated: 1 of 200] 2018-08-09 16:37:10,535 DEBUG PoolingHttpClientConnectionManager:326 - Connection released: [id:98473][route: {}->http://tenantweb-prd1.ypubtanent.svc.gz.n.jd.local:80][totalkept alive: 0; route allocated: 0 of 50; total allocated: 0 of 200] 2018-08-09 16:37:12,201 DEBUG PoolingHttpClientConnectionManager:414 - Closing expired connections 2018-08-09 16:37:17,201 DEBUG PoolingHttpClientConnectionManager:414- Closing expired connections 2018-08-09 16:37:22,201 DEBUG PoolingHttpClientConnectionManager:414 - Closing expired connections

证实连接没释放。(不得不感叹写http连接池的大牛们牛叉,log打印的可读性极好)为什么连接没释放?

查看TCP状态 lsof -i -a -p $java_pid

java6408michael381uIPv6111364900t0TCPlocalhost:46768->localhost:webcache(CLOSE_WAIT) java 6408 michael 382u IPv6 11136494 0t0 TCP localhost:46770->localhost:webcache(close_WAIT) java 6408 michael 383u IPv6 11135941 0t0 TCP localhost:46790->localhost:webcache(CLOSE_WAIT) java 6408 michael 384u IPv6 11134910 0t0 TCP localhost:46792->localhost:webcache(CLOSE_WAIT) java 6408 michael 385u IPv6 11137709 0t0 TCP localhost:46802->localhost:webcache(CLOSE_WAIT) java 6408 michael 386u IPv6 11135974 0t0 TCP localhost:46804->localhost:webcache(CLOSE_WAIT)

可以看到链接都是处于close_wait状态。

查了一些资料得知:

close_wait状态是通信双方中的服务端主动关闭了链接,于是请求发起方的操作系统收到了FIN指令,然后在系统层面将链接状态调整为close_wait状态,接着请求发起方的应用程需要再执行关闭动作,然后链接才能释放。如果请求方的应用没有执行关闭动作,那么connection会一直处于close_wait状态,直到应用程序重启,这个close_wait状态的链接才能释放。

所以从这里看出,如果应用没有对链接资源进行及时的资源释放,就会导致链接泄漏,随着时间发展,应用的可用链接资源就越来越少,当链接资源都被消耗光后,就会出现无可用连接故障。

查看代码怀疑异常时连接没释放。

try{ httpResponse=this.delegate.execute(httpUriRequest); logger.info("this.delegate.executeafter"); status = httpResponse.getStatusLine().getStatusCode(); }catch(Exception e){ //异常请求释放连接 httpUriRequest.abort(); }

httpUriRequest.abort();

# 确保低级别资源释放 中止异常请求

修复后再上线,服务持续正常。

4、小结


1、http连接池的原理理解和连接参数、超时时间参数如何合理设置。

2、遇到问题的解决思路:缩小问题范围、聚焦具体问题服务;怀疑问题、验证怀疑;定位问题工具的运用(日志、相关查看资源命令要熟悉)

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页