一次性能优化,tps从400+到4k+

项目介绍

路由网关项目watchman ,接收前端http请求转发到后端业务系统,功能安全验证,限流,转发。

使用技术:spring boot+ nreflix zuul,最开始日志使用slf4j+log4j部署方式打成jar包,内部使用的是tomcat容器,设置线程数600。

工作原理

先介绍下zuul的工作原理,看图zuul中定义了四种filter分别是

1.pre 在请求到达origin之前执行,在这一步可以做认证,选择转发地址,记录日志

2.Routing 建立http请求,可以使用httpClient或者netflix的ribbon

3.Post 返回请求,可以在这一步做统计收集,设置response的http heder,把请求返回个客户端

4.Error当在以上三个步骤执行出错时执行

 

 

问题

 

性能压测时,tps只有400多,开启并发10个线程和100线程结果一致

分析

watchman中无任何业务逻辑,没有数据库连接操作,没有频繁io操作 只有安全验校验类和限流类,直觉上感觉肯定有问题,代码结构如下

使用jprofiler分析,首先查看CPU views下的call Tree,方法调用链路栈,

按调用时间算的百分比,最高的是WrappingRunable下面有10个百分比较高的http,这10个http就是本次压测的接口。每个接口的占用比都差不多,展开第一个9%的

同样是route为啥preroute耗时这么久,肯定有问题

一个请求进入会依次被三种filter处理,第一种prefilter,第二种route,第三组postroute,初步定为preroute有问题,结合代码看,本次开发pre包中只有两个prefilter一个是AppUrsTokenPreFilter,对app请求解签验签,另一个prefilter做流量控制,仔细检查了代码发现没有问题,spring源码包中有5个prefilter类,查看代码没有问题,没有找到问题换个方向

cpuload猜想

从cpu load看,一直很高,联想到cpu与计算有关,然后AppUrsTokenPreFilter filter中有动态md5的计算,可能与这个类有关系,验证把该类从容器中排除,继续压测,最终结果和之前一致,cpu并没有降下去,猜想错误

堆GC分析

一切正常,继续换方向

线程dump分析

通过观察thread监控,发现50个线程并发时只有5个线程处于runnable状态,其余BLOCKED和waiting,加到线程数到200, runnable还是只有个位数运行,194个BLOCKED,如图。到这可以猜测代码有大量锁竞争

使用jstack dump线程日志,全局搜索blocked 第12行 BLOCKED

其他先不管看到loadclass查看源码,同步锁。。。,问题已找到

接下来查看在哪里调用的,FormBodyWrapperFilter 137行,看代码,spring内置的一个prefilter 作用是针对form表单请求把参数进行转换,使用的是MappingJackson2HttpMessageConverter,其中在构造函数中是这样的

又调用了Jackson2ObjectMapperBuilder,继续看代码

继续看代码Jackson2ObjectMapperBuilder这个类

继续看代码,还是Jackson2ObjectMapperBuilder这个类里的

快到源头了,继续 ,这次到classutils类了

forname方法太长 我只截了关键部分

这个就是源头,loadclass使用的是同步锁

解决问题方法禁用spring自带的prefilter类zuulzuul.FormBodyWrapperFilter.pre.disable=true,改完之后重新部署压测,瞬间上去了

 

还没有结束

之前把自己写的两个prefilter代码注释,加上去之后重新压测,tps瞬间只有一半(红线是kill)

继续线程dump查看。是的你没看错 log4j已经成为了瓶颈 

看log4j源码

从这边可以看到在转发loggingEvent到各个appender的时候,是同步的,即使你用asycAppender也没有效果,解决方法使用logback,再压测一把,平均4k+,可以接受

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页